Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=608332 Jussi Lehtola <jussi.lehtola@xxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |jussi.lehtola@xxxxxx AssignedTo|nobody@xxxxxxxxxxxxxxxxx |jussi.lehtola@xxxxxx Flag| |fedora-review+ --- Comment #3 from Jussi Lehtola <jussi.lehtola@xxxxxx> 2010-11-18 11:26:41 EST --- Actually rpmlint output is rootplot.noarch: E: explicit-lib-dependency python-matplotlib rootplot.noarch: W: spelling-error Summary(en_US) matplotlib -> matelote, matrilocal, marplot rootplot.noarch: W: spelling-error %description -l en_US pyROOT -> pyrostat, pyrope, pyrone rootplot.noarch: W: spelling-error %description -l en_US matplotlib -> matelote, matrilocal, marplot rootplot.noarch: W: no-manual-page-for-binary rootplot rootplot.noarch: W: no-manual-page-for-binary tree2hists rootplot.src: W: spelling-error Summary(en_US) matplotlib -> matelote, matrilocal, marplot rootplot.src: W: spelling-error %description -l en_US pyROOT -> pyrostat, pyrope, pyrone rootplot.src: W: spelling-error %description -l en_US matplotlib -> matelote, matrilocal, marplot 2 packages and 0 specfiles checked; 1 errors, 8 warnings. All of these are OK, though. The explicit lib dependency is only relevant in binary packages, where RPM automatically adds dependencies on the necessary shared libraries. (In reply to comment #1) > So the remaining issues are: > > - Use macros rather than vars consistently (e.g. buildroot). Actually, the spec file does not mix styles. The only thing this applies is using $RPM_OPT_FLAGS vs %{optflags} and $RPM_BUILD_ROOT vs %{buildroot}. The choice between these is a matter of personal preference. > - You can use "python" directly. Yes, there's not much sense in using macros for standard stuff, such as %{__rm}, %{__mv}, %{__mkdir}, %{__mkdir_p} and so on even if they are implemented in RPM. Although, using them is not forbidden. > - The latest upstream version is 2.2. > - Use %{python_sitelib}/root2matplotlib etc. so that you do not own all of > sitelib. This is not a problem per se, the rootplot package only ends up owning the directories that are in %{python_sitelib} *in the build root*. What ends up being owned by %{python_sitelib}/* is (on F14) /usr/lib/python2.7/site-packages/root2matplotlib /usr/lib/python2.7/site-packages/rootplot-1.1-py2.7.egg-info /usr/lib/python2.7/site-packages/rootplot_scripts Still, IMHO using wildcards when they are not absolutely necessary is a bit of bad style; for instance you won't notice if e.g. egg-info isn't built for some reason. I highly recommend being more verbose, i.e. using %{python_sitelib}/root2matplotlib/ %{python_sitelib}/rootplot_scripts/ %{python_sitelib}/rootplot-%{version}-py*.egg-info instead of the needlessly general wildcard glob. - Patch0 is missing a comment in the spec file. Please document its purpose, e.g. # Patch to remove shbangs from Python library Patch0: rootplot-rm-shbangs.patch - I'm not sure why you want to use the conditionals in %if ! (0%{?fedora} > 12 || 0%{?rhel} > 5) %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")} %endif I'd scrap the %if stuff altogether. *** Review: MUST: The package does not yet exist in Fedora. The Review Request is not a duplicate. OK MUST: The spec file for the package is legible and macros are used consistently. OK MUST: The package must be named according to the Package Naming Guidelines. OK MUST: The spec file name must match the base package %{name}. OK MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines. OK MUST: The License field in the package spec file must match the actual license. OK - License is MIT Modern style with sublicense http://fedoraproject.org/wiki/Licensing/MIT MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. OK 016f11836fb3764dd89dd5f0c290816b rootplot-1.1.tar.gz 016f11836fb3764dd89dd5f0c290816b ../SOURCES/rootplot-1.1.tar.gz MUST: The package MUST successfully compile and build into binary rpms. OK MUST: The spec file MUST handle locales properly. N/A MUST: Optflags are used and time stamps preserved. OK MUST: Packages containing shared library files must call ldconfig. N/A MUST: A package must own all directories that it creates or require the package that owns the directory. OK MUST: Files only listed once in %files listings. OK MUST: Debuginfo package is complete. OK MUST: Permissions on files must be set properly. OK MUST: Large documentation files must go in a -doc subpackage. N/A MUST: All relevant items are included in %doc. Items in %doc do not affect runtime of application. ~OK - Maybe add PKG-INFO to %doc? MUST: Header files must be in a -devel package. N/A MUST: Static libraries must be in a -static package. N/A MUST: If a package contains library files with a suffix then library files ending in .so must go in a -devel package. N/A MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency. N/A MUST: Packages does not contain any .la libtool archives. N/A MUST: Desktop files are installed properly. N/A MUST: No file conflicts with other packages and no general names. OK SHOULD: %{?dist} tag is used in release. OK SHOULD: If the package does not include license text(s) as separate files from upstream, the packager should query upstream to include it. NEEDSWORK - No license texts in the tarball. SHOULD: The package builds in mock. OK EPEL: Clean section exists. OK EPEL: Buildroot cleaned before install. OK EPEL: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'. N/A ** Please tend to the issues reported above before import to git. Especially update to newest upstream as instructed by Michael in comment #2, and check that running the examples work. This package has been APPROVED -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review