Hide Forgot
Fedora Merge Review: sabayon http://cvs.fedoraproject.org/viewvc/devel/sabayon/ Initial Owner: tbzatek@redhat.com
Good: - rpmlint checks return: sabayon.spec:98: W: mixed-use-of-spaces-and-tabs (spaces: line 9, tab: line 98) The specfile mixes use of spaces and tabs for indentation, which is a cosmetic annoyance. Use either spaces or tabs for indentation, not both. Trivial to fix. sabayon.x86_64: W: private-shared-object-provides /usr/lib64/python2.7/site-packages/sabayon/xlib.so xlib.so()(64bit) A shared object soname provides is provided by a file in a path from which other packages should not directly load shared objects from. Such shared objects should thus not be depended on and they should not result in provides in the containing package. Get rid of the provides if appropriate, for example by filtering it out during build. Note that in some cases this may require disabling rpmbuild's internal dependency generator. Fix. sabayon.x86_64: W: dangerous-command-in-%postun userdel FIX. We don't remove users, ever. https://fedoraproject.org/wiki/Packaging:UsersAndGroups sabayon-apply.x86_64: E: executable-marked-as-config-file /etc/X11/xinit/xinitrc.d/sabayon-xinitrc.sh Executables must not be marked as config files because that may prevent upgrades from working correctly. If you need to be able to customize an executable, make it for example read a config file in /etc/sysconfig. Fix. sabayon-apply.x86_64: E: script-without-shebang /etc/X11/xinit/xinitrc.d/sabayon-xinitrc.sh This text file has executable bits set or is located in a path dedicated for executables, but lacks a shebang and cannot thus be executed. If the file is meant to be an executable script, add the shebang, otherwise remove the executable bits or move the file elsewhere. Fix. sabayon-apply.x86_64: W: no-manual-page-for-binary sabayon-apply Each executable in standard binary directories should have a man page. Fix if possible. Lots of wrong fsf address, file upstream. - package meets naming guidelines - package meets packaging guidelines - license ( GPLv2+ ) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on devel (x86) - no missing BR - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - no need for .desktop file So it's just what's from rpmlint, let me know if you want me to commit any fixes.
Ping?
(In reply to comment #2) > Ping? I don't think we would want to do the review/fixes at this moment since Sabayon doesn't work with Gnome 3 and upstream is discussing about the project future. Thank you for the review, but let's give this a low priority until Sabayon's fate is decided.
(In reply to comment #1) > So it's just what's from rpmlint, let me know if you want me to commit any > fixes. Feel free to commit any fixes though.
Any rough ETA on that decision?
(In reply to comment #5) > Any rough ETA on that decision? There's no active discussion at the moment, Sabayon future was questioned several times with connection to this Google Summer of Code project, which could replace some functionality: http://www.google-melange.com/gsoc/project/google/gsoc2012/trz/11001 It could take months (years?) before we get Sabayon in an usable shape.
Got it. I committed indentation fixes and removed the user deletion, and we can leave it at that for now. Post here when you hear something.
status? Should it be closed now?
No, though I see you've taken this over. I'll re-review and post my findings.
- rpmlint checks return: sabayon.src: E: specfile-error warning: bogus date in %changelog: Wed Sep 20 2007 Matthias Clasen <mclasen@redhat.com> - 2.20.1-1 This error occurred when rpmlint used rpm to query the specfile. The error is output by rpm and the message should contain more information. I've fixed this. private-shared-object-provides, incorrect-fsf-address, executable-marked-as-config-file, script-without-shebang, no-manual-page-for-binary from above. I'm not going to hold this up on those, though you should look into the private-shard-object-provides if you get a chance. - package meets naming guidelines - package meets packaging guidelines - license ( GPLv2+ ) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream - package compiles on devel (x86_64) - no missing BR - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - no need for .desktop file Fixes applied, APPROVED, closing.