Bug 557760 - Merge Review: sabayon
Summary: Merge Review: sabayon
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-22 14:23 UTC by Tomáš Bžatek
Modified: 2015-03-03 22:44 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-09-10 12:25:00 UTC
Type: ---
Embargoed:
gwync: fedora-review+


Attachments (Terms of Use)

Description Tomáš Bžatek 2010-01-22 14:23:36 UTC
Fedora Merge Review: sabayon

http://cvs.fedoraproject.org/viewvc/devel/sabayon/
Initial Owner: tbzatek

Comment 1 Gwyn Ciesla 2012-04-05 19:34:59 UTC
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.

Comment 2 Gwyn Ciesla 2012-04-26 13:39:33 UTC
Ping?

Comment 3 Tomáš Bžatek 2012-04-26 13:51:58 UTC
(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.

Comment 4 Tomáš Bžatek 2012-04-26 13:52:48 UTC
(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.

Comment 5 Gwyn Ciesla 2012-04-26 13:57:55 UTC
Any rough ETA on that decision?

Comment 6 Tomáš Bžatek 2012-04-26 14:12:43 UTC
(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.

Comment 7 Gwyn Ciesla 2012-04-26 16:38:21 UTC
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.

Comment 8 Christopher Meng 2013-09-10 09:49:12 UTC
status? Should it be closed now?

Comment 9 Gwyn Ciesla 2013-09-10 11:58:16 UTC
No, though I see you've taken this over.  I'll re-review and post my findings.

Comment 10 Gwyn Ciesla 2013-09-10 12:25:00 UTC
- rpmlint checks return: 

sabayon.src: E: specfile-error warning: bogus date in %changelog: Wed Sep 20 2007 Matthias Clasen <mclasen> - 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.


Note You need to log in before you can comment on or make changes to this bug.