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/
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
(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.
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
(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?
(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.
(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.
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
Our sponsor is David Nalley (cc-ed in this review).
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
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.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.
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
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
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.
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
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.
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.
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?
New Official tarball is now available: http://www.ovirt.org/releases/stable/src/ovirt-engine-sdk-1.3.tar.gz 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
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.
[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]
BLOCKER: Please fix the buildarch problem. I'll run rpmlint again and then finish the sponsorship process. Package looks quite nice now. Regards -steve
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
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
PACKAGE APPROVED.
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
New Package SCM Request ======================= Package Name: ovirt-engine-sdk Short Description: SDK for oVirt-Engine platform Owners: oschreib Branches: el6 InitialCC: mpastern
Git done (by process-git-requests).
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
ovirt-engine-sdk-1.3-1.el6 has been pushed to the Fedora EPEL 6 stable repository.
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?
No new branches requested.
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