Bug 1230968

OK, before I do a full review, a few comments:

1) The summary and descriptions don't convey enough information about what functionality the package provides.

2) Guidelines stipulate we should be building py3 packages, so all the conditional stuff about py3 building really is unnecessary for a Fedora package and could be removed.

Package Review
==============

ISSUES:
1) Summary and description don't convey enough information

2) Although the project contains the MIT license for the project, none of the project source files carry a copyright header to that effect. Please work with upstream to get that rectified. Contents of licensecheck.txt (generated by fedora-review):

Unknown or generated
--------------------
livereload-2.4.0/%{py3dir}/livereload/__init__.py
livereload-2.4.0/%{py3dir}/livereload/cli.py
livereload-2.4.0/%{py3dir}/livereload/handlers.py
livereload-2.4.0/%{py3dir}/livereload/server.py
livereload-2.4.0/%{py3dir}/livereload/vendors/livereload.js
livereload-2.4.0/%{py3dir}/livereload/watcher.py
livereload-2.4.0/%{py3dir}/setup.py
livereload-2.4.0/livereload/__init__.py
livereload-2.4.0/livereload/cli.py
livereload-2.4.0/livereload/handlers.py
livereload-2.4.0/livereload/server.py
livereload-2.4.0/livereload/vendors/livereload.js
livereload-2.4.0/livereload/watcher.py
livereload-2.4.0/setup.py



Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed



===== MUST items =====

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "Unknown or generated". 14 files have unknown license. Detailed
     output of licensecheck in /home/jgu/Fedora/1230968-python-
     livereload/licensecheck.txt

But see above: the files themselves really should contain a license header.

[x]: License file installed when any subpackage combination is installed.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Package is not known to require an ExcludeArch tag.
[-]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 20480 bytes in 2 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: 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 is included in %license.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

Python:
[x]: Python eggs must not download any dependencies during the build
     process.
[x]: A package which is used by another package via an egg interface should
     provide egg info.
[x]: Package meets the Packaging Guidelines::Python
[x]: Package contains BR: python2-devel or python3-devel
[x]: Binary eggs must be removed in %prep

===== SHOULD items =====

Generic:
[x]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[x]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in
     python3-livereload
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====
Generic:
[!]: Spec file according to URL is the same as in SRPM.
     Note: Spec file as given by url is not the same as in SRPM (see
     attached diff).
     See: (this test has no URL)

I am reviewing the spec file included in the SRPM. As a point of reference, the SPEC file in the BZ ticket should always match that included in the SRPM.

[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).


Rpmlint
-------
Checking: python-livereload-2.4.0-.fc22.1.noarch.rpm
          python3-livereload-2.4.0-.fc22.1.noarch.rpm
          python-livereload-2.4.0-.fc22.1.src.rpm
python-livereload.noarch: W: no-manual-page-for-binary livereload
python3-livereload.noarch: W: no-manual-page-for-binary livereload
3 packages and 0 specfiles checked; 0 errors, 2 warnings.

These are all fine.


Rpmlint (installed packages)
----------------------------
python-livereload.noarch: W: no-manual-page-for-binary livereload
python3-livereload.noarch: W: no-manual-page-for-binary livereload
2 packages and 0 specfiles checked; 0 errors, 2 warnings.



Diff spec file in url and in SRPM
---------------------------------
--- /home/jgu/Fedora/1230968-python-livereload/srpm/python-livereload.spec      2015-06-15 10:31:33.501294188 +0100
+++ /home/jgu/Fedora/1230968-python-livereload/srpm-unpacked/python-livereload.spec     2015-06-11 22:34:42.000000000 +0100
@@ -10,5 +10,5 @@
 Name:           python-%{pypi_name}
 Version:        2.4.0
-Release:        1%{?dist}
+Release:        %{?dist}.1
 Summary:        Tool for web developers
 
@@ -97,5 +97,5 @@
 %changelog
* Thu Jun 11 2015 William Moreno Reyes <williamjmorenor at gmail.com> 
-- 2.4.0-1
+- 2.4.0-.1
 - Initial packaging
 


Requires
--------
python-livereload (rpmlib, GLIBC filtered):
    /usr/bin/python3
    python(abi)
    python-six
    python-tornado

python3-livereload (rpmlib, GLIBC filtered):
    /usr/bin/python3
    python(abi)
    python3-six
    python3-tornado



Provides
--------
python-livereload:
    python-livereload

python3-livereload:
    python3-livereload



Source checksums
----------------
https://pypi.python.org/packages/source/l/livereload/livereload-2.4.0.tar.gz :
  CHECKSUM(SHA256) this package     : 662e422406184ad0b764bce464742cc2b9a0e7184e684b1b500af03d88ecf40d
  CHECKSUM(SHA256) upstream package : 662e422406184ad0b764bce464742cc2b9a0e7184e684b1b500af03d88ecf40d


Generated by fedora-review 0.6.0 (3c5c9d7) last change: 2015-05-20
Command line :/usr/bin/fedora-review -b 1230968
Buildroot used: fedora-22-x86_64
Active plugins: Python, Generic, Shell-api
Disabled plugins: Java, C/C++, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP, Ruby
Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6




So, in summary, you need to 

1) update Summary and descriptions to be more useful. 

2) Have upstream add license headers to all the files for clarification.

Item 2 seems not to be mandated by the packaging guidelines as far as I can see, so I won't hold off on approval of that, but please do report it upstream.


You may want to simplify the spec file by removing all the py3 conditional stuff, but I'm not insisting on that as it does no harm, and actually I see some of it is from the example spec in the python packaging guidelines.

Spec URL: http://rmsconsultoresnicaragua.com/rpmdev/python-livereload.spec
SRPM URL: http://rmsconsultoresnicaragua.com/rpmdev/python-livereload-2.4.0-.fc22.2.src.rpm
Description: Command line utility for starting a server in a directory

* Mon Jun 15 2015 Fedora <williamjmorenor> 
- 2.4.0-2
- Fix home URL
- Add more details in %%description and %%summary

I wan to go to epel7 where there is not python3 so I will keep the python3 conditionals and define the the %%license macro to %{!?_licensedir:%global license %%doc} also for epel7.

I have opened a issue upstream to work in the copyright header and in  a manpage

https://github.com/lepture/python-livereload/issues/112

Ok, some further issues/questions:

1) Now your descriptions for the py2 and py3 packages differ.

2) From the new description I see this is a command line utility, not a python library. If my understanding is correct, I don't see the need for the python- prefix to the package name.

3) Any reason not to be using the github release page for Source0? (i.e. https://github.com/lepture/python-livereload/releases).

Spec URL: http://rmsconsultoresnicaragua.com/rpmdev/python-livereload.spec
SRPM URL: http://rmsconsultoresnicaragua.com/rpmdev/python-livereload-2.4.0-3.fc22.src.rpm

* Mon Jun 15 2015 William Moreno Reyes <williamjmorenor at gmail.com> 
- 2.4.0-3
- Change to github tarball

I will keep the python- prefix so I will package booth for python 2 and 3

(In reply to William Moreno from comment #6)
> I will keep the python- prefix so I will package booth for python 2 and 3

You're conflating two unrelated things there. And worse, your py3 and py2 packages have file collisions in /usr/bin/livereload.

If it's an end user application rather than the library, then the package name should not include the python prefix. Since supported Fedoras all have py3 available, you should use Python 3 for the package.

If you, for some reason, you also want to have a sub-package that supports python 2, then you should add a -python2 SUFFIX to the name, and you'll need to rename the file in /usr/bin to something else, eg livereload-python2. Or, messily, use the alternatives system.

My recommendation is to drop python 2 support entirely on Fedora, unless the package ALSO contains libraries for use by other programs. In that case, the libs should go in subpackages (python3-livereload-libs, and python-livereload-libs).

I understand your point, I really hate this python 2 and python 3 ecosystem.

I am packaging livereload as a depency for mkdocs and mkdocs requires livereload as library, i will package mkdos only for python 3:

https://github.com/mkdocs/mkdocs/blob/master/setup.py

def _livereload(host, port, config, builder, site_dir):
	
    # We are importing here for anyone that has issues with livereload. Even if
    # this fails, the --no-livereload alternative should still work.

But I do not want to skip the package in a libs package so this is really a small package. Also epel do not have python3 s default and want to add this package in epel.

I can add Provides: livereload in the python 3 package and rename the executable in {_bindir} to livereload-python2 so user can get the python 3 package with dnf install -y livereload and keep the python 2 support for apps than requires python 2 live reload.

A better strategy is:

1) Call the package livereload.
2) Put python 3 libs in a python3-livereload-libs subpackage if python 3 is available.
3) Put python 2 libs in a python-live-reload-libs subpackage
4) If python 3 is available, the main package contains the python3 binary livereload, otherwise the main package contains the python 2 binary livereload.

There's really no value shipping both python 2 and python 3 binaries.

This really is the way to comply with the package guidelines I think.

Spec URL: http://rmsconsultoresnicaragua.com/rpmdev/livereload.spec
SRPM URL: http://rmsconsultoresnicaragua.com/rpmdev/livereload-2.4.0-4.fc22.src.rpm

I will work in support livereload in epel after, but now I will keep only the python 3 support.

OK. The libs subpackage really should be cammed python3-livereload to comply with the package naming guidelines.

:(

I have a bloquer here, during check the python-certifi is downloaded :( to run the test and fedora packages can not download anything from pypi ti build inside mock :( so I will need to package python-certifi and add BuildRequires: python3-certifi

Ejecutando(%check): /bin/sh -e /var/tmp/rpm-tmp.Y2JZmB
+ umask 022
+ cd /home/makerpm/rpmbuild/BUILD
+ cd python-livereload-2.4.0
+ /usr/bin/python3 setup.py test
running test
Searching for certifi
Reading https://pypi.python.org/simple/certifi/
Best match: certifi 2015.4.28
Downloading https://pypi.python.org/packages/source/c/certifi/certifi-2015.04.28.tar.gz#md5=12c7c3a063b2ff97a0f8291d8de41e8c
Processing certifi-2015.04.28.tar.gz
Writing /tmp/easy_install-8z6qqphj/certifi-2015.04.28/setup.cfg
Running certifi-2015.04.28/setup.py -q bdist_egg --dist-dir /tmp/easy_install-8z6qqphj/certifi-2015.04.28/egg-dist-tmp-0u7gk7m6
/usr/lib/python3.4/site-packages/setuptools/dist.py:285: UserWarning: Normalizing '2015.04.28' to '2015.4.28'
  normalized_version,
zip_safe flag not set; analyzing archive contents...
certifi.__pycache__.core.cpython-34: module references __file__
creating /home/makerpm/rpmbuild/BUILD/python-livereload-2.4.0/.eggs/certifi-2015.4.28-py3.4.egg
Extracting certifi-2015.4.28-py3.4.egg to /home/makerpm/rpmbuild/BUILD/python-livereload-2.4.0/.eggs

Installed /home/makerpm/rpmbuild/BUILD/python-livereload-2.4.0/.eggs/certifi-2015.4.28-py3.4.egg
+ exit 0

Spec URL: http://rmsconsultoresnicaragua.com/rpmdev/livereload.spec
SRPM URL: http://rmsconsultoresnicaragua.com/rpmdev/livereload-2.4.0-5.fc22.src.rpm

Ok. I'll pick up the certifi review and we'll work on that first and come back to this.

Spec URL: https://williamjmorenor.fedorapeople.org/rpmdev/livereload.spec
SRPM URL: https://williamjmorenor.fedorapeople.org/rpmdev/livereload-2.4.0-5.fc22.src.rpm

Please note than than the fedora-review will fail to install this package due to the mising Requires: python3-certifi

Why have you removed the libs sub-package? That would seem to be useful to develop against, no?

livereload is a 41.0 package, really I do not find usefull to splip in two a small package like this one, for finall user the diference will be a executable under /usr/bin , a mange and two plain text file for license and readme.

OK, I actually disagree - having the files under sitelib in a separate python-livereload package would be helpful for developers who want to build applications against it and have no use of the command line utility. For instance, does mkdocs need the command line utility, or just the python library?

Looking at here:

https://github.com/mkdocs/mkdocs/blob/a2bdd221d81d456e7cc9d394d1fac90c5507ba5b/mkdocs/cli.py
https://github.com/mkdocs/mkdocs/blob/a2bdd221d81d456e7cc9d394d1fac90c5507ba5b/mkdocs/commands/serve.py

mkdocs do not import liverload as a library, mkdosc requires the command to serve the testwebsite through click

OK. Nothing mandates splitting out the libs, so I'll approve this review, but keep an eye on future consumers of this package - if apps start to be developed against the libs, splitting them out would be a good idea.

APPROVED.

Gah, I just noticed in this updated spec file you're gzipping the man pages manually - please don't do that. RPM compresses the man files automatically during package build, and may in the future use a different compression strategy, so don't compress them manually. just install the uncompressed man pages in %install, and let RPM handle it.

https://fedoraproject.org/wiki/Packaging:Guidelines#Manpages

Thanks for the review.

I will install the man uncompresed

New Package SCM Request
=======================
Package Name: livereload
Short Description: Command line utility for starting a server in a directory
Upstream URL: https://github.com/lepture/python-livereload
Owners: williamjmorenor
Branches: master f22
InitialCC: williamjmorenor

Git done (by process-git-requests).

python-certifi-2015.04.28-5.fc22,livereload-2.4.0-8.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/python-certifi-2015.04.28-5.fc22,livereload-2.4.0-8.fc22

Package python-certifi-2015.04.28-5.fc22, livereload-2.4.0-8.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing python-certifi-2015.04.28-5.fc22 livereload-2.4.0-8.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-11367/python-certifi-2015.04.28-5.fc22,livereload-2.4.0-8.fc22
then log in and leave karma (feedback).

python-certifi-2015.04.28-5.fc22, livereload-2.4.0-8.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

hmm so I see it was actually suggested in the review to have library packaged in subpackages like python-livereload and python3-livereload. Wish if packaging had done like that only.

The libs could still be split out if needed, Parag. Perhaps work with William to make that happen?