Bug 1077030

Summary: Review Request: python-semantic-version - library implementing SemVer
Product: [Fedora] Fedora Reporter: Michael Hrivnak <mhrivnak>
Component: Package ReviewAssignee: Miroslav Suchý <msuchy>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: bwalker, e, i, mhrivnak, msuchy, package-review, williamjmorenor
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-07-22 01:45:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michael Hrivnak 2014-03-17 03:15:07 UTC
This is my first package submission, so I need a sponsor.

Spec URL: http://mhrivnak.fedorapeople.org/python-semantic-version.spec
SRPM URL: http://mhrivnak.fedorapeople.org/python-semantic-version-2.3.0-1.fc20.src.rpm
Description: This small python library provides a few tools to handle SemVer
(http://semver.org) in Python. It follows strictly the 2.0.0 version of the
SemVer scheme.

Fedora Account System Username: mhrivnak

F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6639178
F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6639176

It also builds successfully in el6, and I will want to get it into EPEL6.

Comment 1 John Dulaney 2014-05-13 15:06:30 UTC
Have reviewed it and found one minor issue; that is being corrected.  Otherwise, looks fine.  Needs a sponsor to review, however.

Comment 2 Michael Hrivnak 2014-05-13 15:23:00 UTC
I have corrected one spelling issue in the python3 package description. The SRPM and spec file linked above have been updated.

New scratch builds:
F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6846292
F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6846312

Comment 3 William Moreno 2014-11-23 03:00:31 UTC
*** Bug 1161968 has been marked as a duplicate of this bug. ***

Comment 4 Miroslav Suchý 2015-01-15 10:48:36 UTC
You are missing dot at the end of %description of python3 subpackage.

It is habit (but just habit) to put %check section between %install and %files.

I would consider putting htmldocds in separate -doc subpackage. But I will accept if you hesitate to create it.

Is this:
  python3 -c 'import locale; print(locale.getpreferredencoding(False))'
needed. Or it is just forgotten statement?

Beside that, it looks good. Normally, I would approve this package (because nothing is really blocker), but because this is your first package in Fedora I would kindly ask you to address these issues first.

Comment 5 William Moreno 2015-03-20 00:18:35 UTC
Any update here?

I will try to package python-frappe and it requires python-semantic-version 

https://github.com/frappe/frappe/blob/develop/requirements.txt

There is more than a month ago last update here :(

Comment 6 Michael Hrivnak 2015-03-23 18:08:13 UTC
William, sorry for the delay. In the 7 months that elapsed before Miroslav's review, this fell off my radar. I'll try to make time soon to get my head back in this space and wrap it up.

Comment 7 William Moreno 2015-05-21 01:14:46 UTC
Hello

There is more than a year since this review is open, you make a good job with the spec but it still need some minor fixes, but the last update you made to your spec is around a year ago (2014-05-1), so do you want to mantain this package? I a year you can fix your spec and lookfor a sponsor, may a mail to packaging.org it will be easy to find a sponsor.

So this is your first package I do not want to close it and package semantic-versión by my self so, do you want to mantain this package in Fedora? It so, please fix your spec and respond with a comment, I will try to help you to find a sponsor, you will find your package review template at the end.

If you do not want, please tell me to close this review and package this tool, I will just fix your spec, even you can be a comantainer.

ERPNext 5 was released this week and ERPNext Requires python-semantic-version.

https://github.com/frappe/erpnext/blob/develop/requirements.txt
https://github.com/frappe/frappe/blob/develop/requirements.txt


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

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

Issues:
=======
- 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.
  Note: License file LICENSE is marked as %doc instead of %license
  See:
  http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text

===== MUST items =====
Generic:
[ ]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[ ]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "Unknown or generated". 28 files have unknown license. Detailed
     output of licensecheck in /home/makerpm/1077030-python-semantic-
     version/licensecheck.txt
[ ]: License file installed when any subpackage combination is installed.
[ ]: Package contains no bundled libraries without FPC exception.
[ ]: Changelog in prescribed format.
[ ]: Sources contain only permissible code or content.
[ ]: Each %files section contains %defattr if rpm < 4.4
     Note: %defattr present but not needed
[ ]: Package contains desktop file if it is a GUI application.
[ ]: Development files must be in a -devel package
[ ]: Package uses nothing in %doc for runtime.
[ ]: Package consistently uses macros (instead of hard-coded directory
     names).
[ ]: Package is named according to the Package Naming Guidelines.
[ ]: Package does not generate any conflict.
[ ]: Package obeys FHS, except libexecdir and /usr/target.
[ ]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[ ]: Requires correct, justified where necessary.
[ ]: Spec file is legible and written in American English.
[ ]: Package contains systemd file(s) if in need.
[ ]: 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 860160 bytes in 76 files.
[ ]: 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]: 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:
[ ]: Python eggs must not download any dependencies during the build
     process.
[ ]: A package which is used by another package via an egg interface should
     provide egg info.
[ ]: 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:
[ ]: Buildroot is not present
     Note: Buildroot: present but not needed
[ ]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[ ]: Final provides and requires are sane (see attachments).
[ ]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in python3
     -semantic-version
[ ]: Package functions as described.
[ ]: Latest version is packaged.
[ ]: Package does not include license text files separate from upstream.
[ ]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[ ]: Package should compile and build into binary rpms on all supported
     architectures.
[ ]: %check is present and all tests pass.
[ ]: 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]: 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:
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Spec file according to URL is the same as in SRPM.

Rpmlint
-------
Checking: python-semantic-version-2.3.0-1.fc21.noarch.rpm
          python3-semantic-version-2.3.0-1.fc21.noarch.rpm
          python-semantic-version-2.3.0-1.fc21.src.rpm
python-semantic-version.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/python-semantic-version/htmldocs/_static/jquery.js
python-semantic-version.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/python-semantic-version/htmldocs/objects.inv
python-semantic-version.noarch: W: file-not-utf8 /usr/share/doc/python-semantic-version/htmldocs/objects.inv
python3-semantic-version.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/python3-semantic-version/htmldocs/_static/jquery.js
python3-semantic-version.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/python3-semantic-version/htmldocs/objects.inv
python3-semantic-version.noarch: W: file-not-utf8 /usr/share/doc/python3-semantic-version/htmldocs/objects.inv
3 packages and 0 specfiles checked; 0 errors, 6 warnings.

Rpmlint (installed packages)
----------------------------
python3-semantic-version.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/python3-semantic-version/htmldocs/_static/jquery.js
python3-semantic-version.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/python3-semantic-version/htmldocs/objects.inv
python3-semantic-version.noarch: W: file-not-utf8 /usr/share/doc/python3-semantic-version/htmldocs/objects.inv
python-semantic-version.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/python-semantic-version/htmldocs/_static/jquery.js
python-semantic-version.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/python-semantic-version/htmldocs/objects.inv
python-semantic-version.noarch: W: file-not-utf8 /usr/share/doc/python-semantic-version/htmldocs/objects.inv
2 packages and 0 specfiles checked; 0 errors, 6 warnings.

Requires
--------
python3-semantic-version (rpmlib, GLIBC filtered):
    python(abi)

python-semantic-version (rpmlib, GLIBC filtered):
    python(abi)

Provides
--------
python3-semantic-version:
    python3-semantic-version

python-semantic-version:
    python-semantic-version

Source checksums
----------------
https://github.com/rbarrois/python-semanticversion/archive/v2.3.0.tar.gz :
  CHECKSUM(SHA256) this package     : 5856f3ef6397d832f4c7ac297654d9c75f54bd3289a47680f84c0bb8293ad372
  CHECKSUM(SHA256) upstream package : 5856f3ef6397d832f4c7ac297654d9c75f54bd3289a47680f84c0bb8293ad372

Comment 8 Eduardo Mayorga 2015-06-06 22:04:02 UTC
As per the Policy for stalled package reviews, I'll wait for one week from now for you to comment on this ticket. Otherwise, I'll close this ticket with resolution NOTABUG.
See: https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews

Comment 9 Michael Hrivnak 2015-06-09 14:47:37 UTC
I will make time to finish this up this month. Thanks for the reminder.

Comment 10 Michael Hrivnak 2015-07-02 01:23:13 UTC
I have made the improvements as requested and updated to upstream's 2.4.1 release. I am currently working with upstream to fix two bugs that prevent unit tests from passing with django 1.7 and newer.

https://github.com/rbarrois/python-semanticversion/issues/22

Everything builds successfully on el6 and el7, and as soon as I have a solution for the test failures with fedora (and its newer django), I'll post a new srpm and spec file for review.

Comment 12 Miroslav Suchý 2015-07-03 08:32:30 UTC
> Source0: https://github.com/rbarrois/python-semanticversion/archive/v2.4.2.tar.gz

Unless upstream change the format each release, you should rather use:

Source0: https://github.com/rbarrois/python-semanticversion/archive/v%{version}.tar.gz

as it will keep the spec' diff minimal on each release.


> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildRoot is not needed since F10
  https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag
Unless you want to build this for EL5 you should remove it.

Can you move %check after %install? This will easy reading to our pure humans. Because rpmbuild first execute %prep, then %build, followed by %install and only then %check. So if you sort the section in your spec this way, is more readable.


> export LC_ALL=en_US.UTF-8
> %{__python3} setup.py build

This should be rather rewritten as:
LC_ALL=en_US.UTF-8 %{__python3} setup.py build

so the LC is set just for that one command.
Similarly in %install section.


> pushd docs && make html
> popd && mv docs/_build/html htmldocs

I see no reasons why to use &&. All scriptlets are execute with "-e" therefore if any command will fail, build will  immediately stopped.
In fact if docs directory will be missing, the first line will just mask it. And second line will either fail or popd into unexpected directory.

> %defattr(-,root,root,-)
Again - not needed unless you aim EL5.

> %{!?_licensedir:%global license %%doc}
no need to define it twice. And I woule personally move it to top of the file, where other macros are defined.

I would consider putting htmldocds in separate -doc subpackage. It is quite big, especially because it bundle jquery. But I will accept if you hesitate to create it (with some reasoning).

Comment 13 Michael Hrivnak 2015-07-06 22:20:09 UTC
Thanks for the help. I have made the changes locally, but have two questions, both related to el6.

I agree that moving the _licencedir stuff to the top makes sense, but when I do so, the el6 build reports this error:

----------------
Processing files: python-semantic-version-2.4.2-1.el6.noarch
error: File must begin with "/": BSD
error: File must begin with "/": LICENSE
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.B95reb
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd python-semanticversion-2.4.2
+ DOCDIR=/root/rpmbuild/BUILDROOT/python-semantic-version-2.4.2-1.el6.x86_64/usr/share/doc/python-semantic-version-2.4.2
+ export DOCDIR
+ rm -rf /root/rpmbuild/BUILDROOT/python-semantic-version-2.4.2-1.el6.x86_64/usr/share/doc/python-semantic-version-2.4.2
+ /bin/mkdir -p /root/rpmbuild/BUILDROOT/python-semantic-version-2.4.2-1.el6.x86_64/usr/share/doc/python-semantic-version-2.4.2
+ cp -pr ChangeLog README.rst /root/rpmbuild/BUILDROOT/python-semantic-version-2.4.2-1.el6.x86_64/usr/share/doc/python-semantic-version-2.4.2
+ exit 0


RPM build errors:
    File must begin with "/": BSD
    File must begin with "/": LICENSE
----------------

If I move the same line back to right above the use of "%license", the error goes away. Any ideas?

Question 2: After making the requested changes, I get the following errors on el6 from rpmlint. I believe this is why I had the "%defattr" use "Buildroot" usage. Since I plan to get this into epel6 also, can/should I keep those statements in the spec file? Or is there some other solution that's better?


----------
python-semantic-version.spec:129: E: files-attr-not-set
python-semantic-version.spec:130: E: files-attr-not-set
python-semantic-version.spec:131: E: files-attr-not-set
python-semantic-version.spec:132: E: files-attr-not-set
python-semantic-version.spec:136: E: files-attr-not-set
python-semantic-version.spec:137: E: files-attr-not-set
python-semantic-version.spec:138: E: files-attr-not-set
python-semantic-version.spec:142: E: files-attr-not-set
python-semantic-version.spec:143: E: files-attr-not-set
python-semantic-version.spec: W: no-cleaning-of-buildroot %install
python-semantic-version.spec: W: no-cleaning-of-buildroot %clean
python-semantic-version.spec: W: no-buildroot-tag
python-semantic-version.spec: W: no-%clean-section
----------

Comment 14 William Moreno 2015-07-21 04:30:41 UTC
Sorry but we need semantic-version at less in f23 and rawhide due to:

https://bugzilla.redhat.com/show_bug.cgi?id=1233101

Quote:
This message is a reminder that Fedora 23 Change Checkpoint: Completion deadline (testable) is on 2015-07-28 [1]

Comment 15 Miroslav Suchý 2015-07-21 10:19:42 UTC
> I agree that moving the _licencedir stuff to the top makes sense, but when I do so, the el6 build reports this error:

It is weird. I have no idea why it is happening. Ok, you can keep it there.

> Question 2: After making the requested changes, I get the following errors on el6 from rpmlint.

According:
https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions
It is not needed since rpm 4.4 and rhel6 contains rpm-4.8
If rpmlint warns you, then I would say it is rpmlint issue. However if you feel bad about those warning, you can keep it there if you want to. It is really harmless.

Can you please post SRPM with remaining issues from #12 fixed. I can then give you approval stamp.

Comment 16 William Moreno 2015-07-21 22:35:48 UTC
This app is alredy in Fedora since 2015-05-28

https://admin.fedoraproject.org/pkgdb/package/python-semantic_version/

Comment 17 Christopher Meng 2015-07-22 01:45:37 UTC

*** This bug has been marked as a duplicate of bug 1207280 ***

Comment 18 William Moreno 2015-07-22 02:04:03 UTC
Michael Hrivnak  you made a great job with the spec, you can request to become a comantainer of semantic version.

Please remember than for your firts package you do not need to go for all the suported epel releases