Spec URL: http://jkaluza.fedorapeople.org/swift.spec SRPM URL: http://jkaluza.fedorapeople.org/swift-1.0-0.1.beta5.fc13.src.rpm Description: Swift is easy to use XMPP client which is trying to plug a hole in the XMPP client landscape.
Another package called "swift". I have asked the packager of the other one if changing the name to "OpenStack-swift" would be acceptable: https://bugzilla.redhat.com/show_bug.cgi?id=617632#c3 For the record: We already know the upstream developer of this swift would not object to the package name "swift-im".
%description should be longer. Where does swift.xpm (Source2) come from? You do not need to define "BuildRoot:..." anymore, rpmbuild will use a sane one automatically (since F-10). You do not need to clean the buildroot manually at the beginning of %install (since F-10). You do not need the %clean section either (since F-13). http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag It's good that you remove bundled libraries in %prep. Only why you do not remove all of them? The "3rdParty" directory still contains: Boost CppUnit DocBook hippomocks.h LCov
617632 will update its name to prefix it with openstack, you're welcome to use the swift name.
I've updated the spec file and srpm: Spec URL: http://jkaluza.fedorapeople.org/swift.spec SRPM URL: http://jkaluza.fedorapeople.org/swift-1.0-0.2.beta5.fc13.src.rpm (In reply to comment #2) > %description should be longer. Fixed. > Where does swift.xpm (Source2) come from? It was brought from Debian package, but I've just removed it and new spec file uses icon from Source0 tarball. > You do not need to define "BuildRoot:..." anymore, rpmbuild will use a sane one > automatically (since F-10). > You do not need to clean the buildroot manually at the beginning of %install > (since F-10). > You do not need the %clean section either (since F-13). > http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag Thanks, fixed. > It's good that you remove bundled libraries in %prep. Only why you do not > remove all of them? The "3rdParty" directory still contains: > Boost CppUnit DocBook hippomocks.h LCov I've removed all unused bundled libraries. DocBook is still used, because build fails with DocBook from rawhide. I will ask upstream for help, but it's only build-time dependency, so it should not be problem just now.
(In reply to comment #3) > 617632 will update its name to prefix it with openstack, you're welcome to use > the swift name. Thanks for fast response regarding the name conflict and also for the solution.
Let's take a look at rpmlint: > $ rpmlint swift-1.0-0.2.beta5.fc13.src.rpm > swift.src: W: no-cleaning-of-buildroot %install > swift.src: W: no-cleaning-of-buildroot %clean > swift.src: W: no-buildroot-tag > swift.src: W: no-%clean-section > swift.src: W: invalid-url Source0: swift-1.0beta5.tar.gz No actual problem so far. > $ rpmlint swift-1.0-0.2.beta5.fc14.x86_64.rpm > swift.x86_64: W: incoherent-version-in-changelog 1.0-0.2beta5 ['1.0-0.2.beta5.fc14', '1.0-0.2.beta5'] This points out a real bug. Missing dots in changelog entries' versions. > swift.x86_64: W: no-documentation > swift.x86_64: W: no-manual-page-for-binary swift These are real, but not blockers. Formal review according to Review Guidelines: Explanation: [ok] .... the package meets the guideline item [--] .... the guideline item is not relevant for this package [ERR] ... the package fails to meet the guideline and must be fixed. ==================== [ok] rpmlint must be run on every package. [ok] named according to the Package Naming Guidelines. [ok] The spec file name must match the base package %{name} [ERR] License must be Fedora approved; Licensing Guidelines. [ERR] The License field in the package spec file must match the actual license. [ERR] license file must packaged in %doc. The spec says "License: GPLv3+", but the sources appear to be under GPL v3 only (no later version). The tarball contains the text of the license in the "COPYING" file - it should be included as %doc in the binary package. [ok] spec file in American English. [ok] spec legible. [ok] sources must match the upstream source I verified the steps to create the tarball from upstream git resulted in the same files within the tarball. [ok] must compile and build. [--] ExcludeArch if it does not. [ok] complete and sensible BuildRequires [--] handling of locales [--] ldconfig for dynamic libs [ok] Packages must NOT bundle copies of system libraries. Bundled libs are correctly removed in %prep. The only remaining directory is DocBook, containing xml files and images. Since they do not end up in the binary and may only influence how documentation is built (and there currently is not any in the binary package), I find it acceptable. It would be nice to find out why it cannot build with DocBook from Fedora though. [--] rules for relocatable packages [ok] directory ownership [ok] no duplicate listing in %files [ok] sane permissions; %defattr(...) [ERR] consistent macro usage The uses both %{buildroot} and ${RPM_BUILD_ROOT}. Choose one and stick to it. [ok] code or permissable content [--] large doc [--] header files [--] static libs [--] .so in -devel [--] devel requires base package [--] remove .la files [ok] GUI app must include a %{name}.desktop and use desktop-file-install [ok] no owning of other packages' files/dirs [ok] UTF-8 filenames Formal review according to Packaging Guidelines: [ok] naming [ok] version and release [ERR] Licensing (already mentioned above) [ok] no inclusion of pre-built binaries or libraries [ok] spec legibility [ok] arch support [ok] filesystem layout [ERR] changelogs (as already noted by rpmlint) [ok] tags [ok] BuildRoot (not needed, the package is only for Rawhide) [ok] Requires [ok] BuildRequires [ok] summary and description [ok] encoding [ERR] compiler flags I don't see %{optflags} being applied. Koji build log indicates they are not passed (for instance, there's no mention of _FORTIFY_SOURCE). [ok] debuginfo [--] devel packages [--] libraries [ok] no duplication of system libraries [ok] no rpath [--] config files [--] initscripts [ok] desktop files [ok] Icon tag in Desktop Files BTW, a PNG is usually preferred nowadays, but XPM is acceptable. [ERR] macros (inconsistent usage, as already noted) [--] handling locale files [ERR] timestamps swift.xpm is installed without using "-p". [--] parallel make (at least I have no idea how it applies to scons) [--] scriptlets [--] conditional deps [--] relocatable packages [ok] code vs content [ok] file and dir ownership [--] users and groups [--] web apps [ok] no conflicts [ok] no kernel modules [ok] nothing in /srv [ok] no bundling [ok] no fonts bundling [--] patches should have upstream bug link or comment [--] epoch [--] symlinks [--] man pages (always nice to have, but not necessary)
Spec URL: http://jkaluza.fedorapeople.org/swift.spec SRPM URL: http://jkaluza.fedorapeople.org/swift-1.0-0.3.beta5.fc13.src.rpm kojid build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2379059 > [ERR] License must be Fedora approved; Licensing Guidelines. > [ERR] The License field in the package spec file must match the actual license. > [ERR] license file must packaged in %doc. > > The spec says "License: GPLv3+", but the sources appear to be under GPL v3 only > (no later version). > The tarball contains the text of the license in the "COPYING" file - it should > be included as %doc in the binary package. Just now it's "License: GPLv3". COPYING file is installed too. > [ERR] consistent macro usage > > The uses both %{buildroot} and ${RPM_BUILD_ROOT}. Choose one and stick to it. Only %{buildroot} is used now. > I don't see %{optflags} being applied. Koji build log indicates they are not > passed (for instance, there's no mention of _FORTIFY_SOURCE). Fixed. > BTW, a PNG is usually preferred nowadays, but XPM is acceptable. For 32x32 px size, upstream provides only .xpm icon in. If other sizes are allowed (I couldn't find it anywhere), I can install .png. > [ERR] timestamps > > swift.xpm is installed without using "-p". Fixed.
Everything looks OK now. One suggestion: Use xz instead of gzip for the tarball. You'll get a significantly smaller srpm. APPROVED. Proceed with SCM admin request. I know the final release of swift is not expected before the release of Fedora 14 and you want the package only in Rawhide for now, but I think you should request the f14 branch to be created too, in order to have it ready for the swift 1.0 release within Fedora 14 lifetime.
New Package SCM Request ======================= Package Name: swift Short Description: XMPP client Owners: jkaluza Branches: f14 InitialCC: michich
Should this package name be 'swift' or 'Swift'? The bug summary says one, but the package says the other. Could you clarify before we add the package?
Sorry for the confusion, it should be "swift". I will correct the summary, too.
Git done (by process-git-requests).
Thanks for the review and Git branch. Everything is done, so I'm closing this review request.
swift-1.0-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/swift-1.0-1.fc14
swift-1.0-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/swift-1.0-2.fc14
swift-1.0-2.fc14 has been pushed to the Fedora 14 stable repository.
Package Change Request ====================== Package Name: swift New Branches: el6 Owners: jkaluza
swift-2.0-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/swift-2.0-1.el6
swift-2.0-1.el6 has been pushed to the Fedora EPEL 6 stable repository.