Bug 771111

Summary: Review Request: ovirt-engine-sdk - SDK for oVirt-Engine platform
Product: [Fedora] Fedora Reporter: Ofer Schreiber <oschreib>
Component: Package ReviewAssignee: Steven Dake <sdake>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: acathrow, athmanem, bazulay, david, iheim, juan.hernandez, mpastern, notting, oourfali, package-review, sdake
Target Milestone: ---Flags: sdake: fedora‑review+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-24 16:56:52 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Ofer Schreiber 2012-01-01 09:01:22 EST
Spec URL: http://oschreib.fedorapeople.org/ovirt-engine-sdk/ovirt-engine-sdk.spec
SRPM URL: http://oschreib.fedorapeople.org/ovirt-engine-sdk/ovirt-engine-sdk-1.0-1.src.rpm
Description:
ovirt-engine-sdk is a python SDK for the oVirt-engine project.

oVirt-Engine is a feature-rich virtualization management platform.
More info can be found at http://www.ovirt.org/about/
Comment 1 Athmane Madjoudj 2012-01-01 10:12:59 EST
Here's some comments (I'm not a packager):

- Changelog entry does not have version-release number
  ref: http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs

- You can use %{version} %{release} macros in Source0 url

- If you're not going to support epel5, you can remove %defattr and BuildRoot definition

- Source in SRPM and URL does not match (sha1):

67a2941be6370a011bdb8535108b2b75181f4a3e  ovirt-engine-sdk-1.0-1.tar.gz
558f6bde9b2904fc30018f1b0f9e8914b007710e  ovirt-engine-sdk-1.0-1.tar.gz
Comment 2 Ofer Schreiber 2012-01-01 10:23:25 EST
(In reply to comment #1)
> Here's some comments (I'm not a packager):
> 
> - Changelog entry does not have version-release number
>   ref: http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs

Fixed.

> 
> - You can use %{version} %{release} macros in Source0 url\

Fixed.

> 
> - If you're not going to support epel5, you can remove %defattr and BuildRoot
> definition

I don't know about that yet

> 
> - Source in SRPM and URL does not match (sha1):
> 
> 67a2941be6370a011bdb8535108b2b75181f4a3e  ovirt-engine-sdk-1.0-1.tar.gz
> 558f6bde9b2904fc30018f1b0f9e8914b007710e  ovirt-engine-sdk-1.0-1.tar.gz

Fixed.

Thanks for the review.
Comment 3 Athmane Madjoudj 2012-01-01 10:33:13 EST
Some other things (after building rpm):

- You should make 'xml/params.py' executable or remove shebang (if it used as module)
See: 
http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Remove_shebang_from_Python_libraries


- You need to include a license file or contact upstream to include it.
See: http://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text
Comment 4 Ofer Schreiber 2012-01-01 11:03:03 EST
(In reply to comment #3)
> Some other things (after building rpm):
> 
> - You should make 'xml/params.py' executable or remove shebang (if it used as
> module)
> See: 
> http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Remove_shebang_from_Python_libraries

Fixed locally (and uploaded new rpms). Upstream informed.

> 
> 
> - You need to include a license file or contact upstream to include it.
> See: http://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text

Contacted upstream. Are you sure this package MUST include a license file? where should we deploy it?
Comment 5 Athmane Madjoudj 2012-01-01 11:10:02 EST
(In reply to comment #4)
> (In reply to comment #3)
<...>
> 
> > 
> > 
> > - You need to include a license file or contact upstream to include it.
> > See: http://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text
> 
> Contacted upstream. Are you sure this package MUST include a license file?
> where should we deploy it?

Should be included in %doc with (README and AUTHORS).

From http://fedoraproject.org/wiki/Packaging:LicensingGuidelines:

License Text

If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. If the source package does not include the text of the
^^^^^^^^^^^^^^^^^^^^^^^^^
license(s), the packager should contact upstream and encourage them to correct this mistake.
Comment 6 Ofer Schreiber 2012-01-01 11:37:49 EST
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> <...>
> > 
> > > 
> > > 
> > > - You need to include a license file or contact upstream to include it.
> > > See: http://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text
> > 
> > Contacted upstream. Are you sure this package MUST include a license file?
> > where should we deploy it?
> 
> Should be included in %doc with (README and AUTHORS).
> 
> From http://fedoraproject.org/wiki/Packaging:LicensingGuidelines:
> 
> License Text
> 
> If (and only if) the source package includes the text of the license(s) in its
> own file, then that file, containing the text of the license(s) for the package
> must be included in %doc. If the source package does not include the text of
> the
> ^^^^^^^^^^^^^^^^^^^^^^^^^
> license(s), the packager should contact upstream and encourage them to correct
> this mistake.

Added README and AUTHORS to the doc dir. Still waiting to the LICENSE file from upstream.
Thanks for the review.
Comment 7 Steven Dake 2012-01-01 12:20:52 EST
Ofer,

I am a packager and can provide reviews of other packagers packages, but you need a Sponsor (see https://admin.fedoraproject.org/accounts/group/members/packager/*/sponsor for a list of sponsors) to provide the review so that you can eventually make it into the packagers group (this allows people in the "Packagers" group to review your packages).

Lets get started to help the sponsor out a bit.

The tarball is constructed incorrectly.  There should only be a directory in the top level of the tarball.

instead of:

-rw-rw-r-- oschreib/oschreib 343 2011-12-15 06:49 .gitignore
-rw-rw-r-- oschreib/oschreib 364 2011-12-15 06:49 .project
-rw-rw-r-- oschreib/oschreib 426 2011-12-15 06:49 .pydevproject
-rw-rw-r-- oschreib/oschreib 103 2011-12-15 06:49 .settings/org.eclipse.core.res
ources.prefs
-rw-rw-r-- oschreib/oschreib  99 2011-12-15 06:49 AUTHORS
-rw-rw-r-- oschreib/oschreib 123 2011-12-15 06:49 MANIFEST.in
-rw-rw-r-- oschreib/oschreib 1008 2011-12-27 07:51 Makefile
-rw-rw-r-- oschreib/oschreib 1760 2011-12-15 06:49 README
-rw-rw-r-- oschreib/oschreib 1577 2012-01-01 09:34 ovirt-engine-sdk.spec.in
-rw-rw-r-- oschreib/oschreib 2089 2011-12-15 06:49 parser_lex.py
-rw-rw-r-- oschreib/oschreib 10274 2011-12-15 06:49 parser_tab.py
-rw-rw-r-- oschreib/oschreib   925 2011-12-27 07:51 setup.py
-rw-rw-r-- oschreib/oschreib   529 2012-01-01 06:06 src/ovirt_engine_sdk.egg-inf
o/PKG-INFO

It should be something like:

/ovirt-engine-sdk/All those files

The tarball files should not have group writeable permissions.  

I assume this problem occurs because upstream hasn't made a release of the software.  Provide feedback to upstream to ensure the release process produces correct tarballs.

This will allow you to remove the lines:

%{__install} -p -m 644 AUTHORS %{buildroot}%{_defaultdocdir}/%{name}/
%{__install} -p -m 644 README %{buildroot}%{_defaultdocdir}/%{name}/

And change:
%doc %{_defaultdocdir}/%{name}/AUTHORS
%doc %{_defaultdocdir}/%{name}/README

to 
%doc AUTHORS
%doc README

It is generally frowned upon to put upstream repository snapshots in Fedora.  Encourage upstream to make a tarball release.  This may be a blocker issue for the Sponsor reviewer (I am not certain on this point).

Please adjust the spec and rpm as per this message and then I'll walk through list of review MUST and SHOULDs.

Regards
-steve
Comment 8 Oved Ourfali 2012-01-01 13:15:00 EST
Our sponsor is David Nalley (cc-ed in this review).
Comment 9 Ofer Schreiber 2012-01-01 14:48:14 EST
Steve,

Many thanks for your reply.
I'm working closely with oVirt upstream community in order to create the right release process.

I've uploaded a new set of TAR/SRPM/SPEC into http://oschreib.fedorapeople.org/ovirt-engine-sdk/ and I hope it will fix all the issues mentioned above.

-Ofer
Comment 10 Steven Dake 2012-01-01 17:55:25 EST
Initial take on spec file:
1. Release should be:

Release: 1%{?dist}

This will trigger .fc16 or .fc17 to be placed in the rpm spec file.

2. BuildRoot is no longer needed in Fedora.  Please remove these lines.

3. BuildArch is not needed in Fedora.  Please remove these lines.

4. %clean section is no longer needed in Fedora.  Please remove this section.

5. %{python_sitelib}/ovirtsdk is an unowned dir.  To own it, change the line to:
%dir %attr(0755, root, root) %{python_sitelib}/ovirtsdk

6. The %description section should contain more details and proper sentences rather then a Summary (this is what %summary is for).  For example : This package contains The oVirt Software Development Kit.  With this package, custom software can be built for ovirt (or whatever it does..).

7. The %install section should not contain anything that removes the buildroot.  Remove:
 [ "%{buildroot}" != "/" ] && rm -rf %{buildroot}

8. The #Source0 should be removed.  checked in spec files should not have "commented out code".

9. What is oschreib@redhat.com.org?  Please correct the changelog.

10. If I was a sponsor, I would not approve a package for a snapshot of a source repository that was not released as an official upstream artifact.

MUST review next.
Comment 11 Steven Dake 2012-01-01 18:11:45 EST
MUST: rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review.[1] 

[root@beast noarch]# rpmlint ovirt-engine-sdk-1.0-1.noarch.rpm
ovirt-engine-sdk.noarch: W: summary-not-capitalized C oVirt Engine Software Development Kit
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

[root@beast SRPMS]# rpmlint ovirt-engine-sdk-1.0-1.src.rpm
ovirt-engine-sdk.src: W: summary-not-capitalized C oVirt Engine Software Development Kit
ovirt-engine-sdk.src:9: W: macro-in-comment %{version}
ovirt-engine-sdk.src:9: W: macro-in-comment %{release}
1 packages and 0 specfiles checked; 0 errors, 3 warnings.

not capitalized warning will be resolved by using a proper description.
macro in comment should go away with the deletion of #Source

MUST: The package must be named according to the Package Naming Guidelines .

Typically software development kits would be named "devel" ie:

ovirt-engine-devel

QUESTION: Is there some rationale for not using -devel?

MUST: The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption. [2] . 

PASS

MUST: The package must meet the Packaging Guidelines .
MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines .

PASS

MUST: The License field in the package spec file must match the actual license. [3]

This is difficult to tell.  Only setup.py contains the license type.

UPSTREAM REQUEST: Please file a bug with upstream to place license text in every source file.

MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.[4]

The license is not in the source tarball.  It is typical for packages to include the license in the source tree and include it as a %doc.

UPSTREAM REQUEST: Please file a bug with upstream to place the full license file in the tarball.
 
MUST: The spec file must be written in American English. [5]

PASS

MUST: The spec file for the package MUST be legible. [6]

PASS

MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this.

If I were a sponsor I would not approve this package as there is no upstream release of the software.  However, the files do match.

MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture. [7]

PASS

MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line. [8]

N/A

MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense.

Will review in the python-specific requirements.

MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.[9]

N/A

MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. [10]

N/A

MUST: Packages must NOT bundle copies of system libraries.[11]

N/A

MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. [12]

N/A

MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. [13]

FAIL: %{python_sitelib}/ovirtsdk is an unowned directory.

MUST: A Fedora package must not list a file more than once in the spec file's %files listings. (Notable exception: license texts in specific situations)[14]

PASS

MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. [15]

PASS

MUST: Each package must consistently use macros. [16]

FAIL: %dist is not properly used in the Release field.

MUST: The package must contain code, or permissable content. [17]

PASS

MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity). [18]

N/A

MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. [18]

N/A

MUST: Header files must be in a -devel package. [19]

N/A

MUST: Static libraries must be in a -static package. [20]

N/A

MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. [19]

N/A

MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name}%{?_isa} = %{version}-%{release} [21]

N/A

MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.[20]

N/A

MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. [22]

N/A

MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. [23]

PASS

MUST: All filenames in rpm packages must be valid UTF-8. [24]

PASS
Comment 12 Steven Dake 2012-01-01 18:23:15 EST
PYTHON specific review guidelines:

MUST To build a package containing python2 files, you need to have
BuildRequires: python2-devel

FAIL: Please remove the odd BuildRequires

setup.py should be executable in the tarball

Please remove the python_sitelib macros.  These are not needed in Fedora.

Must: Python eggs must be built from source. They cannot simply drop an egg from upstream into the proper directory. (See prebuilt binaries Guidelines for details)

PASS


Must: Python eggs must not download any dependencies during the build process.

PASS

Must: When building a compat package, it must install using easy_install -m so it won't conflict with the main package.

N/A

Must: When building multiple versions (for a compat package) one of the packages must contain a default version that is usable via "import MODULE" with no prior setup.
Should: A package which is used by another package via an egg interface should provide egg info.

N/A
Comment 13 Ofer Schreiber 2012-01-02 04:57:05 EST
I've uploaded a new TAR/SRPM/SPEC into http://oschreib.fedorapeople.org/ovirt-engine-sdk/ with fixes for all the issues mentioned above.

upstream notified about the licensing issues, I hope to get a new license files soon (and a official tarball release as well).

Few questions/notes:
1. I've noticed that after removing the BuildArch, rpmlint complains "E: no-binary", is that OK?
2. About the unowned dir: I thought that specifying a dir name without the "dir" prefix includes the dir with all the content inside. after fixing that, rpmbuild complains "warning: File listed twice: /usr/lib/python2.7/site-packages/ovirtsdk", is that OK?
3. About *-devel naming: the upstream project is called "ovirt-engine-sdk", So I thought it's the right name for this package.
Comment 14 David Nalley 2012-01-04 09:00:23 EST
So a couple of additional comments: 

1. Please increment the changelog and release every time you make a change. 
2. So while I can appreciate that there isn't yet a 'release' and thus you are building from a point in time - I really have some issues with versioning here, and think that calling this 1.0 will create headaches for you down the road. (I am presuming that we don't know if the next release will be 1.0 or 0.1, but regardless there will be version conflicts.) 

I'd propose you take a look at: 
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages

If it were me, I'd set version to: 
0.0 
and I'd set release to something like: 
2.20120104git9e88d7e%{dist}

Also, it's well and fine (if a bit of extra work for the person reviewing your packages) for you to host your own tarball - but you need to add comments to tell us how you got their. One of the things about packages is that it should provide some auditability and repeatability, and while I have faith that you aren't changing source from upstream, I need to be able to create an identical tarball, so provide comments under the source URL that shows me how you generated it so I can generate a replica myself. 

See: https://fedoraproject.org/wiki/Packaging:SourceURL#Using_Revision_Control
Comment 15 Ofer Schreiber 2012-01-09 10:22:06 EST
Official tarball is now available: http://www.ovirt.org/releases/stable/binary/ovirt-engine-sdk-1.0-1.tar.gz

SRPM: http://oschreib.fedorapeople.org/ovirt-engine-sdk/ovirt-engine-sdk-1.0-1.fc16.src.rpm
SPEC: http://oschreib.fedorapeople.org/ovirt-engine-sdk/ovirt-engine-sdk.spec

Now, about the release/version: I'm not sure I completely understood the convention.
1. Should the rpm version/release match the upstream one? 
2. If I'll name it 0.0-2.20120104git9e88d7e%{dist} should I update the changelog accordingly? 

#2 is a bit problematic since the upstream already contains the spec file, so I'll have to commit it after every build I'll do for this review.
I thought it would be better to first pass this review with the right version (e.g. 1.0-1) and then add updates to the changelog.
Comment 16 David Nalley 2012-01-09 11:10:19 EST
Glad the tarball is out, that greatly simplifies things. 

I don't know how closely you are working with upstream - but typically release is something that the distro handles e.g. if they have a choice in future naming of their tarballs only include name and version, and let release be handled by Fedora. 

RPM version should generally always match upstream versioning. There are some exceptions, largely documented in this section: 
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning

Release however tends to be distro specific - so every time you change the spec file you'll increment the release. While it seems bothersome now, and the problem you cite with including spec file is an issue. There are lots of builds that will increment the changelog/release and you'll have no control over, so for instance, there's a mass rebuild of all Fedora packages going on now (or very shortly) for a new gcc version. That means an incremented release and an additional changelog entry (and new builds of the software going out). Also keep in mind that others (those in the provenpackager group) can touch your packages, modify spec files, etc. So you might get $version-1 into the repo for a given tag. Most folks who include a spec files make it a pretty generalized, working spec file in the source repo. Sheepdog is a decent example of this: 
https://github.com/collie/sheepdog/blob/master/sheepdog.spec.in

Keep in mind you'll be checking your spec file into a package-specific git repo and maintaining it there for Fedora and EPEL.
Comment 17 Ofer Schreiber 2012-01-09 11:48:07 EST
I think we're fine here, we don't include the spec file itself in the git/tarball, we include ovirt-engine-sdk.spec.in, which is pretty generalized, although we can do some better job there.

About versioning - I think that if tarball version is 1.0-1, the first rpm will be 1.0-1 and we will add .1/2/3 in the end of the release for every additional build. anyhow, I didn't thought of adding changelog entries during this review (only afterwards), if it's required, I'll add it.

Anything more I should do before starting the official review?
Comment 19 Steven Dake 2012-02-07 09:55:29 EST
David had said he was really swamped and I could take on sponsorship of your package if I liked.  

Your reviews of the following packages are fairly complete and show an understanding of the packaging process:
1. https://bugzilla.redhat.com/show_bug.cgi?id=787858
2. https://bugzilla.redhat.com/show_bug.cgi?id=787834
3. https://bugzilla.redhat.com/show_bug.cgi?id=787293
4. https://bugzilla.redhat.com/show_bug.cgi?id=786668
5. https://bugzilla.redhat.com/show_bug.cgi?id=787364 

I'll make another review of your spec/srpm and sponsor you once the package has met guidelines.
Comment 20 Steven Dake 2012-02-07 10:19:32 EST
[FAIL] MUST: rpmlint must be run on the source rpm and all binary rpms the build
produces. The output should be posted in the review.[1] 

[root@beast SRPMS]# rpmlint ovirt-engine-sdk-1.3-1.fc16.src.rpm
ovirt-engine-sdk.src: W: summary-not-capitalized C oVirt Engine Software Development Kit
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
[root@beast x86_64]# rpmlint ovirt-engine-sdk-debuginfo-1.3-1.fc16.x86_64.rpm
ovirt-engine-sdk-debuginfo.x86_64: E: empty-debuginfo-package
1 packages and 0 specfiles checked; 1 errors, 0 warnings.
[root@beast x86_64]# rpmlint ovirt-engine-sdk-1.3-1.fc16.x86_64.rpm
ovirt-engine-sdk.x86_64: W: summary-not-capitalized C oVirt Engine Software Development Kit
ovirt-engine-sdk.x86_64: E: no-binary
1 packages and 0 specfiles checked; 1 errors, 1 warnings.

I know I mentioned BuildArch was not necessary.  I was wrong in that assertion.  I'd reocmmend readding it (set to noarch) to fix these problems after having a better understanding of your package.

[PASS] MUST: The package must be named according to the Package Naming Guidelines .

Typically software development kits would be named "devel" ie:

[PASS] MUST: The spec file name must match the base package %{name}, in the format
%{name}.spec unless your package has an exemption. [2] . 

[PASS] MUST: The package must meet the Packaging Guidelines .

[PASS] MUST: The package must be licensed with a Fedora approved license and meet the
Licensing Guidelines .

[PASS] MUST: The License field in the package spec file must match the actual license.
[3]

[PASS] MUST: If (and only if) the source package includes the text of the license(s)
in its own file, then that file, containing the text of the license(s) for the
package must be included in %doc.[4]

[PASS] MUST: The spec file must be written in American English. [5]

[PASS] MUST: The spec file for the package MUST be legible. [6]

[PASS] MUST: The sources used to build the package must match the upstream source, as
provided in the spec URL. Reviewers should use md5sum for this task. If no
upstream URL can be specified for this package, please see the Source URL
Guidelines for how to deal with this.

[root@beast SPECS]# wget http://ovirt.org/releases/stable/src/ovirt-engine-sdk-1.3.tar.gz
--2012-02-07 08:13:27--  http://ovirt.org/releases/stable/src/ovirt-engine-sdk-1.3.tar.gz
Resolving ovirt.org... 173.255.252.138
Connecting to ovirt.org|173.255.252.138|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 99564 (97K) [application/x-gzip]
Saving to: “ovirt-engine-sdk-1.3.tar.gz”

100%[=============================================================================================>] 99,564       576K/s   in 0.2s    

2012-02-07 08:13:27 (576 KB/s) - “ovirt-engine-sdk-1.3.tar.gz” saved [99564/99564]

[root@beast SPECS]# sha256sum ovirt-engine-sdk-1.3.tar.gz
1854650abff3fce7e32ab268e461cb296296435451ded1c46d40b75a5b688b84  ovirt-engine-sdk-1.3.tar.gz
[root@beast SOURCES]# sha256sum ovirt-engine-sdk-1.3.tar.gz
1854650abff3fce7e32ab268e461cb296296435451ded1c46d40b75a5b688b84  ovirt-engine-sdk-1.3.tar.gz

[PASS] MUST: The package MUST successfully compile and build into binary rpms on at
least one primary architecture. [7]

[N/A] MUST: If the package does not successfully compile, build or work on an
architecture, then those architectures should be listed in the spec in
ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in
bugzilla, describing the reason that the package does not compile/build/work on
that architecture. The bug number MUST be placed in a comment, next to the
corresponding ExcludeArch line. [8]

[PASS] MUST: All build dependencies must be listed in BuildRequires, except for any
that are listed in the exceptions section of the Packaging Guidelines ;
inclusion of those as BuildRequires is optional. Apply common sense.

[N/A] MUST: The spec file MUST handle locales properly. This is done by using the
%find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.[9]

[N/A] MUST: Every binary RPM package (or subpackage) which stores shared library
files (not just symlinks) in any of the dynamic linker's default paths, must
call ldconfig in %post and %postun. [10]

[PASS] MUST: Packages must NOT bundle copies of system libraries.[11]

[N/A] MUST: If the package is designed to be relocatable, the packager must state
this fact in the request for review, along with the rationalization for
relocation of that specific package. Without this, use of Prefix: /usr is
considered a blocker. [12]

[PASS] MUST: A package must own all directories that it creates. If it does not create
a directory that it uses, then it should require a package which does create
that directory. [13]

[PASS] MUST: A Fedora package must not list a file more than once in the spec file's
%files listings. (Notable exception: license texts in specific situations)[14]

[PASS] MUST: Permissions on files must be set properly. Executables should be set with
executable permissions, for example. [15]

[PASS] MUST: Each package must consistently use macros. [16]

[PASS] MUST: The package must contain code, or permissable content. [17]

[N/A] MUST: Large documentation files must go in a -doc subpackage. (The definition
of large is left up to the packager's best judgement, but is not restricted to
size. Large can refer to either size or quantity). [18]

[N/A] MUST: If a package includes something as %doc, it must not affect the runtime
of the application. To summarize: If it is in %doc, the program must run
properly if it is not present. [18]

[N/A] MUST: Header files must be in a -devel package. [19]

[N/A] MUST: Static libraries must be in a -static package. [20]

[N/A] MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1),
then library files that end in .so (without suffix) must go in a -devel
package. [19]

[N/A] MUST: In the vast majority of cases, devel packages must require the base
package using a fully versioned dependency: Requires: %{name}%{?_isa} =
%{version}-%{release} [21]

[N/A] MUST: Packages must NOT contain any .la libtool archives, these must be removed
in the spec if they are built.[20]

[N/A] MUST: Packages containing GUI applications must include a %{name}.desktop file,
and that file must be properly installed with desktop-file-install in the
%install section. If you feel that your packaged GUI application does not need
a .desktop file, you must put a comment in the spec file with your explanation.
[22]

[PASS] MUST: Packages must not own files or directories already owned by other
packages. The rule of thumb here is that the first package to be installed
should own the files or directories that other packages may rely upon. This
means, for example, that no package in Fedora should ever share ownership with
any of the files or directories owned by the filesystem or man package. If you
feel that you have a good reason to own a file or directory that another
package owns, then please present that at package review time. [23]

[PASS] MUST: All filenames in rpm packages must be valid UTF-8. [24]
Comment 21 Steven Dake 2012-02-07 10:21:03 EST
BLOCKER: Please fix the buildarch problem.  I'll run rpmlint again and then finish the sponsorship process.

Package looks quite nice now.

Regards
-steve
Comment 22 Ofer Schreiber 2012-02-07 10:59:14 EST
New SRPM and SPEC uploaded: (I didn't add a changelog entry or increased the release, I hope that's fine since it's not official yet)

SRPM:
http://oschreib.fedorapeople.org/ovirt-engine-sdk/ovirt-engine-sdk-1.3-1.fc16.src.rpm

SPEC: http://oschreib.fedorapeople.org/ovirt-engine-sdk/ovirt-engine-sdk.spec
Comment 23 Steven Dake 2012-02-07 11:05:56 EST
Ofer 

In this case, just leave as is.

In the future, *always* update the nvr/changelog when submitting packages for review.  It makes it alot easier on the reviewer (making sure they have correct files) and allows people to audit the review process went correctly.

Thanks
-steve
Comment 24 Steven Dake 2012-02-07 11:07:09 EST
PACKAGE APPROVED.
Comment 25 Steven Dake 2012-02-07 11:08:28 EST
Ofer,

When you receive an email indicating you have joined the packagers group, please submit a scm request.

Congratulations on your first package and nice work executing those other 5 reviews.

Regards
-steve
Comment 26 Ofer Schreiber 2012-02-07 12:58:47 EST
New Package SCM Request
=======================
Package Name: ovirt-engine-sdk
Short Description: SDK for oVirt-Engine platform
Owners: oschreib
Branches: el6
InitialCC: mpastern
Comment 27 Jon Ciesla 2012-02-07 13:05:12 EST
Git done (by process-git-requests).
Comment 28 Fedora Update System 2012-02-07 13:42:44 EST
ovirt-engine-sdk-1.3-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/ovirt-engine-sdk-1.3-1.el6
Comment 29 Fedora Update System 2012-02-16 15:07:00 EST
ovirt-engine-sdk-1.3-1.el6 has been pushed to the Fedora EPEL 6 stable repository.
Comment 30 Juan Hernández 2012-08-24 14:09:22 EDT
Package Change Request
======================
Package Name: ovirt-engine-sdk
Owners: oschreib jhernand

We need to update these package in order to fix bug 851674 and CVE-2012-3533, but my colleage Ofer Schreiber will not be available for the next few weeks, so he can't grant me commit permissions via the package database pages. Can you grant me those permissions somehow?
Comment 31 Jon Ciesla 2012-08-24 15:13:41 EDT
No new branches requested.
Comment 32 Steven Dake 2012-08-24 16:56:52 EDT
Juan,

This package review has completed.  Please do not change around the flags on completed review requests.

As for your request to be added to the package database for this package, it appears only the owner can allow new users into the package.  I am a provenpackager and don't see a mechanism to force the addition of your user to the package.

I'd suggest mailing fedora devel for more guidance.

Regards
-steve