Unless you plan to submit this for old EPELs (<7) remove the folowing parts:

- python_sitearch define
- BuildRoot

For python packages using setup.py this standard pattern is normally used:
%build
%{__python2} setup.py build

%install
%{__python2} setup.py install -O1 --skip-build --root=%{buildroot}

New guidelines say that you should say (https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text):
%files
%license LICENSE.txt

SRPM link does not link to the srpm, but to a page... This breaks tools like fedora-review.
You should link to the raw file directly (add ?raw=true at the end of the link for example).

python-setuptools-devel → python-setuptools

From the build:
[WARNING] poppler headers not found, PDF indexation won't work
[WARNING] wv2 not found, DOC indexation won't work
[WARNING] libsoup not found, itools.web won't work
Maybe you can add more build dependencies to enable this.

(In reply to Reiner Rottmann from comment #0)
> Spec URL:
> https://raw.githubusercontent.com/rrottmann/rpmbuild/master/SPECS/python-
> itools.spec
> 
> SRPM URL:
> https://github.com/rrottmann/rpmbuild/blob/master/SRPMS/python-itools-0.75.1-
> 1.fc20.src.rpm
> 
> Description:
> 
> Please note, I am still a new rpm packager. My first rpm package is still in
> review under bz#734248.
> 
> I Had a look at http://fedoraproject.org/wiki/SIGs/Python#Package_requests
> and saw the request to create a Fedora RPM package for itools:
> 
> The itools library offers a collection of packages covering a wide
> range of capabilities.  Including support for many file formats (XML,
> CSV, HTML, etc.), a virtual file system (itools.fs), the simple
> template language (STL), an index and search engine, and much more.
> 
> While this is my first package for a python library, I took the challenge
> and created above SPEC/SRPM files.
> 
> I checked it with rpmlint and got the following warnings:
> 
> python-itools.x86_64: W: devel-file-in-non-devel-package
> /usr/lib64/python2.7/site-packages/itools/xml/doctype.c
> /usr/lib64/python2.7/site-packages/itools/xml/arp.c
> /usr/lib64/python2.7/site-packages/itools/xml/pyparser.c
> /usr/lib64/python2.7/site-packages/itools/xml/parser.h
> /usr/lib64/python2.7/site-packages/itools/web/soup.c
> /usr/lib64/python2.7/site-packages/itools/xml/parser.c
Are they used at runtime or are they just copied by mistake? Probably the latter,
so just nuke them with 'find %{buildroot} \( -name *.[ch] -o -name .mailmap \) -delete'.

> A development file (usually source code) is located in a non-devel package.
> If
> you want to include source code in your package, be sure to create a
> development package.
> 
> python-itools.x86_64: W: hidden-file-or-dir
> /usr/lib64/python2.7/site-packages/itools/.mailmap
> The file or directory is hidden. You should see if this is normal, and delete
> it from the package if not.
It should be removed (see above).

...
> python-itools.x86_64: W: no-manual-page-for-binary ipkg-quality.py
> Each executable in standard binary directories should have a man page.
Should. But doesn't have to. You can try to file a request upstream, or generate
a man page yourself, usign help2man. But please leave this until the end,
this is a significant amount of work and just a "should", not "must".

%doc files are copied into /usr/lib64/python2.7/site-packages/itools/. You
should add an %exclude for them, or remove them after installation.

Runing the programs does not seem to work:
$ /usr/bin/ipkg-build.py
Traceback (most recent call last):
  File "/usr/bin/ipkg-build.py", line 35, in <module>
    from itools.pkg import get_config, get_manifest, open_worktree
ImportError: cannot import name open_worktree

> python-itools.x86_64: W: file-not-in-%lang
> /usr/lib64/python2.7/site-packages/itools/locale/en.mo
> python-itools.x86_64: W: file-not-in-%lang
> /usr/lib64/python2.7/site-packages/itools/locale/es.mo
> python-itools.x86_64: W: file-not-in-%lang
> /usr/lib64/python2.7/site-packages/itools/locale/fr.mo
> python-itools.x86_64: W: file-not-in-%lang
> /usr/lib64/python2.7/site-packages/itools/locale/it.mo
> python-itools.x86_64: W: file-not-in-%lang
> /usr/lib64/python2.7/site-packages/itools/locale/zh.mo
> 1 packages and 0 specfiles checked; 0 errors, 23 warnings.
Hm, I don't know about this, maybe somebody else can chime in.

So the most significant thing is to get the scripts to work I think :)

Thank you for the invaluable input! I have modified the spec accordingly and rebuild the src.rpm:

https://raw.githubusercontent.com/rrottmann/rpmbuild/master/SPECS/python-itools.spec

https://github.com/rrottmann/rpmbuild/blob/master/SRPMS/python-itools-0.75.1-2.fc22.src.rpm?raw=true

In order to get the scripts working, I've updated the dependencies in the spec file.

As python-pygit2 is currently broken in rawhide, I have used the existing src.rpm and bumped the pygit2 version. With the resulting rpm, the python-itools scripts are now working. Here is the src.rpm:

https://github.com/rrottmann/rpmbuild/blob/master/SRPMS/python-pygit2-0.22.0-1.fc22.src.rpm?raw=true

I expect, that this is only an interim solution and will be fixed shortly. Therefore I did not use too much time to tinker with the python-pygit2 spec file.

Please note, the errror handling is very pure in the upstream source of python-itools. In case you call the scripts outside the intended git structure, you are greeted with a python trace instead of some explaining error messages.

The new output of rpmlint:

python-itools.x86_64: W: no-manual-page-for-binary iodf-greek.py
python-itools.x86_64: W: no-manual-page-for-binary ipkg-update-locale.py
python-itools.x86_64: W: no-manual-page-for-binary igettext-build.py
python-itools.x86_64: W: no-manual-page-for-binary idb-inspect.py
python-itools.x86_64: W: no-manual-page-for-binary ipkg-docs.py
python-itools.x86_64: W: no-manual-page-for-binary igettext-merge.py
python-itools.x86_64: W: no-manual-page-for-binary ipkg-build.py
python-itools.x86_64: W: no-manual-page-for-binary ipkg-copyright.py
python-itools.x86_64: W: no-manual-page-for-binary igettext-extract.py
python-itools.x86_64: W: no-manual-page-for-binary ipkg-quality.py
python-itools.x86_64: W: file-not-in-%lang /usr/lib64/python2.7/site-packages/itools/locale/en.mo
python-itools.x86_64: W: file-not-in-%lang /usr/lib64/python2.7/site-packages/itools/locale/es.mo
python-itools.x86_64: W: file-not-in-%lang /usr/lib64/python2.7/site-packages/itools/locale/fr.mo
python-itools.x86_64: W: file-not-in-%lang /usr/lib64/python2.7/site-packages/itools/locale/it.mo
python-itools.x86_64: W: file-not-in-%lang /usr/lib64/python2.7/site-packages/itools/locale/zh.mo
1 packages and 0 specfiles checked; 0 errors, 15 warnings.

Do you have a bug number for the python-pygit2 issue?

> python-itools.x86_64: W: file-not-in-%lang /usr/lib64/python2.7/site-packages/itools/locale/en.mo

See http://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files.

Just filed the bug report bz#1186880 to address the current issue with python-pygit2. A quick search showed, that this was not reported before.

Thanks for reminding me of the packaging guidelines where the locate files are already described. I will look into that.

The spellcorrection caused trouble. I meant locale files.

Hm, I lost track of this ticket. I can review it, but there are some things to fix:

Python packaging guidelines have been nicely simplified. You should now use %py2_build and %py2_install macros, see https://fedoraproject.org/wiki/Packaging:Python.

Summary is useless, 'cause it just duplicates the name. Please succinctly summarize what the package does. Also the %description is a bit unclear: it has something with various formats, but what does the package actually *do*?

Use %version in %prep.

This is an automatic check from review-stats script.

This review request ticket hasn't been updated for some time. We're sorry
it is taking so long. If you're still interested in packaging this software
into Fedora repositories, please respond to this comment clearing the
NEEDINFO flag.

You may want to update the specfile and the src.rpm to the latest version
available and to propose a review swap on Fedora devel mailing list to increase
chances to have your package reviewed. If this is your first package and you
need a sponsor, you may want to post some informal reviews. Read more at
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group.

Without any reply, this request will shortly be considered abandoned
and will be closed.
Thank you for your patience.

This is an automatic action taken by review-stats script.

The ticket submitter failed to clear the NEEDINFO flag in a month.
As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
we consider this ticket as DEADREVIEW and proceed to close it.