Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1344276 - Review Request: gdeploy - Tool to deploy GlusterFS clusters and other utilities
Summary: Review Request: gdeploy - Tool to deploy GlusterFS clusters and other utilities
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Paulo Andrade
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: FE-NEEDSPONSOR
TreeView+ depends on / blocked
 
Reported: 2016-06-09 10:16 UTC by Sachidananda Urs
Modified: 2017-09-10 04:52 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-09 23:51:46 UTC
Type: ---
paulo.cesar.pereira.de.andrade: fedora-review+


Attachments (Terms of Use)

Description Sachidananda Urs 2016-06-09 10:16:15 UTC
Hi,

Request to review the package gdeploy for inclusion in Fedora package repo.
This is my first package, I need a sponsor. I've built a koji build, can
be found here: http://koji.fedoraproject.org/koji/taskinfo?taskID=14422056

Spec URL: http://download.gluster.org/pub/gluster/gdeploy/gdeploy.spec
SRPM URL: http://download.gluster.org/pub/gluster/gdeploy/gdeploy-2.1-0.src.rpm

Description: gdeploy is an Ansible based tool initially built to deploy
GlusterFS. Later enhanced to do more than just deploying GlusterFS clusters, it
handles lot of system administration tasks like installing packages using yum,
subscribing to Red Hat Subscription Management, updating files on remote hosts,
start and stopping services, and lot more. More details and documentation can be
found at: gdeploy.readthedocs.io
 
Fedora Account System Username: sac

Comment 1 Parag AN(पराग) 2016-09-08 03:15:14 UTC
Taking this for review.

Comment 2 Parag AN(पराग) 2016-09-08 07:27:45 UTC
Suggestions:
 As per current packaging guidelines given on https://fedoraproject.org/wiki/Packaging:Guidelines

1) use %global instead of %define, See https://fedoraproject.org/wiki/Packaging:Guidelines#.25global_preferred_over_.25define

2)  In %install, following is now optional and should be removed
rm -rf %{buildroot}

as per https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections

3) Group and BuildRoot tag are not needed now, remove them.

4) Good to write every Require: per line

5) Why every package in Requires: need hard versioned requirement? I think whatever packages are in Fedora should satisfy the requirements and make this package run without any issues. Onlyif it needs some different version then that issue need to be fixed like some package need higher version and if its not yet in Fedora then that package should be updated to that higher version thus no need to write explicit versions

6) You need to go through https://fedoraproject.org/wiki/Packaging:Python which can tell you we now use explicitly "python2" wherever you have used "python"

7) we don't need now %clean section, remove it

8) You may write your spec accordingly python packaging guidelines.

9) I can't find the 2.1.0 tarball on the given source location, fix this

Submit new SPEC and SRPM by fixing above issues and adding new changelog entry. Every time you make some change in SPEC, you need to update the release tag and add changelog.

Comment 3 Parag AN(पराग) 2016-10-07 14:58:15 UTC
Also, I want to note here that we have this process, 
http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group to 
get sponsored into the packager group. Can you either submit few more packages 
and/or some full detailed package reviews? This is needed to make sure package 
submitter understands the rpm packaging well and follows the fedora packaging 
guidelines.

Please go through the following links
1) http://fedoraproject.org/wiki/Package_Review_Process

2) https://fedoraproject.org/wiki/PackagingGuidelines

3) To find the packages already submitted for review,
   check http://fedoraproject.org/PackageReviewStatus/

4) http://fedoraproject.org/wiki/Packaging:ReviewGuidelines and
   http://fedoraproject.org/wiki/Package_Review_Process#Reviewer is useful 
   while doing package reviews.

5) https://fedorahosted.org/FedoraReview/ this is fedora-review tool to help
   review packages in fedora. You need to use this and do un-official package 
   reviews of packages submitted by other contributors. While doing so mention 
   "This is un-official review of the package." at top of your review comment.

Good to review packages listed in http://fedoraproject.org/PackageReviewStatus/NEW.html

When you do full package review of some packages, provide that review comment 
link here so that I can look how you have reviewed those packages.

If you got any questions please ask here or on Freenode IRC join #fedora-devel :)

Comment 4 Ken Dreyer 2016-11-04 19:55:09 UTC
Would you please address each of Parag's comments above and update the package to the latest upstream version?

I'm a sponsor, so I can sponsor you if you would please do one satisfactory unofficial review of a package in Parag's links above, and ensure that this package gets cleaned up.

For example, this sort of boilerplate seems common in the Gluster community and is unneeded:

  %define name gdeploy
  %define version 2.1
  %define release 0

In fact it will break tools like rpmdev-bumpspec that Fedora rel-eng uses for mass rebuilds. It's better to simply define the values directly in the RPM:

  Name:           gdeploy
  Version:        2.1
  Release:        1%{?dist}

The URL should be the upstream project, https://github.com/gluster/gdeploy, not Red Hat's storage website.

Comment 5 Sachidananda Urs 2016-11-05 12:41:38 UTC
(In reply to Ken Dreyer from comment #4)
> Would you please address each of Parag's comments above and update the
> package to the latest upstream version?

Ack! I will do that.

> 
> I'm a sponsor, so I can sponsor you if you would please do one satisfactory
> unofficial review of a package in Parag's links above, and ensure that this
> package gets cleaned up.

Sure, I will do that. Thanks for this.

> 
> For example, this sort of boilerplate seems common in the Gluster community
> and is unneeded:
> 
>   %define name gdeploy
>   %define version 2.1
>   %define release 0
> 
> In fact it will break tools like rpmdev-bumpspec that Fedora rel-eng uses
> for mass rebuilds. It's better to simply define the values directly in the
> RPM:
> 
>   Name:           gdeploy
>   Version:        2.1
>   Release:        1%{?dist}
> 
> The URL should be the upstream project, https://github.com/gluster/gdeploy,
> not Red Hat's storage website.

Sure. I will make these changes. Thanks for helping on this.

Comment 6 Sachidananda Urs 2016-11-07 09:23:20 UTC
(In reply to Parag AN(पराग) from comment #2)
> Suggestions:
>  As per current packaging guidelines given on
> https://fedoraproject.org/wiki/Packaging:Guidelines
> 
> 1) use %global instead of %define, See
> https://fedoraproject.org/wiki/Packaging:Guidelines#.
> 25global_preferred_over_.25define
> 

Done.

> 2)  In %install, following is now optional and should be removed
> rm -rf %{buildroot}
> 
> as per https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections
> 

Done.

> 3) Group and BuildRoot tag are not needed now, remove them.
> 

Done.

> 4) Good to write every Require: per line
> 

Done.

> 5) Why every package in Requires: need hard versioned requirement? I think
> whatever packages are in Fedora should satisfy the requirements and make
> this package run without any issues. Onlyif it needs some different version
> then that issue need to be fixed like some package need higher version and
> if its not yet in Fedora then that package should be updated to that higher
> version thus no need to write explicit versions
> 

Makes sense. However we need version information for Ansible.
Fedora ships 1.x, we need 2.x.

> 6) You need to go through https://fedoraproject.org/wiki/Packaging:Python
> which can tell you we now use explicitly "python2" wherever you have used
> "python"

Done.

> 
> 7) we don't need now %clean section, remove it

Ack.

> 
> 8) You may write your spec accordingly python packaging guidelines.
> 
> 9) I can't find the 2.1.0 tarball on the given source location, fix this
> 

This should not be a problem in future. I will make changes to point to
git tags.

> Submit new SPEC and SRPM by fixing above issues and adding new changelog
> entry. Every time you make some change in SPEC, you need to update the
> release tag and add changelog.

Sure.

Comment 7 Sachidananda Urs 2016-11-09 07:07:27 UTC
Hi I've made changes to the spec file and can be found at: 

https://github.com/gluster/gdeploy/blob/master/gdeploy.spec

I'll request to upload the srpm to a publicly accessible location.
The change I'm not confident in the spec file is the define:

%global _rpmfilename noarch/%{name}-%{version}-%{release}%{?dist}.rpm

I hope this is fine. I need it this way so that I can have a generic
tar.gz source file and build dist specific rpm from that.

Parag I will work on reviewing packages.

Comment 8 Niels de Vos 2016-11-09 08:30:46 UTC
(In reply to Sachidananda Urs from comment #7)
> I'll request to upload the srpm to a publicly accessible location.
> The change I'm not confident in the spec file is the define:
> 
> %global _rpmfilename noarch/%{name}-%{version}-%{release}%{?dist}.rpm
> 
> I hope this is fine. I need it this way so that I can have a generic
> tar.gz source file and build dist specific rpm from that.

I do not understand why this is needed. Could you explain your workflow that requires this? We may be able to suggest an alternative approach.

Comment 9 Parag AN(पराग) 2016-11-10 04:35:18 UTC
I was away for a week for some conference. Reading this review updates now. 

Ken, I see you also offered to sponsor Sachidananda and he has actually responded to your comment and provided update for this package.

I think I will now prefer you to continue this package review and sponsorship to Sachidananda.

Comment 10 Sachidananda Urs 2016-11-10 05:55:18 UTC
(In reply to Niels de Vos from comment #8)
> (In reply to Sachidananda Urs from comment #7)
> > I'll request to upload the srpm to a publicly accessible location.
> > The change I'm not confident in the spec file is the define:
> > 
> > %global _rpmfilename noarch/%{name}-%{version}-%{release}%{?dist}.rpm
> > 
> > I hope this is fine. I need it this way so that I can have a generic
> > tar.gz source file and build dist specific rpm from that.
> 
> I do not understand why this is needed. Could you explain your workflow that
> requires this? We may be able to suggest an alternative approach.

So when I build RPMs I would like to have gdeploy-<version>-release-{fc24,el7,el6}.rpm ... 
And I would like to keep the tar ball gdeploy-<version>-release.tar.gz

I don't want to create a tag for every dist.

Comment 11 Ken Dreyer 2016-11-15 05:16:32 UTC
It seems like you're mixing the Release value and Version values here?

Release is a number that is "downstream" (Fedora) only. Other Fedora maintainers, like ProvenPackagers or Fedora rel-eng, will sometimes bump this Release integer, so it's not something you can completely keep in sync between Fedora downstream and Gluster upstream.

It would be best to avoid having the Release number in your upstream tarballs. To put it another way, "v%{version}-%{release}.tar.gz" should just be "v%{version}.tar.gz"

The "/usr/local/bin/gluster-replace-node" file should not be in /usr/local (see https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fusr.2Flocal.2C_or_.2Fhome.2F.24USER)

The license seems unclear here, because the "LICENSE" file from upstream is the GPLv2, but the .spec here says GPLv3. Which is it? Also, the LICENSE file should be included in the package, via the %license directive.

Comment 12 Ken Dreyer 2016-11-15 05:17:30 UTC
Would you please post raw direct links to the latest .spec and .src.rpm so that the fedora-review tool can process them?

Comment 13 Sachidananda Urs 2016-11-16 10:16:11 UTC
(In reply to Ken Dreyer from comment #11)
> It seems like you're mixing the Release value and Version values here?
> 
> Release is a number that is "downstream" (Fedora) only. Other Fedora
> maintainers, like ProvenPackagers or Fedora rel-eng, will sometimes bump
> this Release integer, so it's not something you can completely keep in sync
> between Fedora downstream and Gluster upstream.
> 
> It would be best to avoid having the Release number in your upstream
> tarballs. To put it another way, "v%{version}-%{release}.tar.gz" should just
> be "v%{version}.tar.gz"

I'll fix that.

> 
> The "/usr/local/bin/gluster-replace-node" file should not be in /usr/local
> (see
> https://fedoraproject.org/wiki/Packaging:
> Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fusr.2Flocal.2C_or_.
> 2Fhome.2F.24USER)
> 
> The license seems unclear here, because the "LICENSE" file from upstream is
> the GPLv2, but the .spec here says GPLv3. Which is it? Also, the LICENSE
> file should be included in the package, via the %license directive.


Ack! I will fix these and update.

Comment 14 tserlin 2016-12-22 21:49:01 UTC
This is un-official review of/comment on the package...


Just to be clear, is this intended to be version 2.1 or 2.0.1? Just a quick glance, but I don't see any mention of 2.1 or a 2.1 branch on the upstream github.

The updated spec file is obviously for 2.0.1.


I get:

ERROR: 'No srpm found for gdeploy' (logs in /home/thomas/.cache/fedora-review.log)

when I run `fedora-review  -m fedora-rawhide-x86_64 -n gdeploy` on the downloaded spec file and source RPM.

Comment 15 Ken Dreyer 2016-12-23 01:31:10 UTC
Sac, would you please post raw direct links to the latest .spec and .src.rpm so that the fedora-review tool can process them? The previous link for the .spec was to GitHub's web UI, and fedora-review needs the raw file.

Comment 16 Sachidananda Urs 2016-12-23 05:44:23 UTC
(In reply to Ken Dreyer from comment #15)
> Sac, would you please post raw direct links to the latest .spec and .src.rpm
> so that the fedora-review tool can process them? The previous link for the
> .spec was to GitHub's web UI, and fedora-review needs the raw file.

Ken, sure will do that.

Comment 17 Sachidananda Urs 2016-12-23 05:49:23 UTC
(In reply to tserlin from comment #14)
> This is un-official review of/comment on the package...
> 
> 
> Just to be clear, is this intended to be version 2.1 or 2.0.1? Just a quick
> glance, but I don't see any mention of 2.1 or a 2.1 branch on the upstream
> github.
> 
> The updated spec file is obviously for 2.0.1.
> 
> 
> I get:
> 
> ERROR: 'No srpm found for gdeploy' (logs in
> /home/thomas/.cache/fedora-review.log)
> 
> when I run `fedora-review  -m fedora-rawhide-x86_64 -n gdeploy` on the
> downloaded spec file and source RPM.

It is 2.0.1 and I will make the changes suggested by Ken and update the bug
with the details.

Comment 19 Ken Dreyer 2017-01-06 17:16:04 UTC
%global gdeploytemp /usr/share/ansible/gdeploy
- Instead of "/usr/share/ansible/gdeploy", why not use "/usr/share/gdeploy"? Putting the files under another package's namespace (ansible) could lead to problems in the future.
- Please use the %{_datadir} macro here instead of /usr/share.

%global gdeploydoc /usr/share/doc/gdeploy
- Please use the %{_pkgdocdir} macro and eliminate %{gdeploydoc}.

install -m 755 extras/usecases/replace-node/gluster-replace-node \
        %{buildroot}/usr/bin
- Do you need to make %{buildroot}/usr/bin here?, or does the earlier "setup.py install" command already create that directory for you?

/usr/bin/gluster-replace-node
- Please use the %{_bindir} macro here

%global _rpmfilename noarch/%{name}-%{version}-%{release}%{?dist}.rpm
I don't think this line is needed.

%description
- "and lot more" -> "and more" (grammar fix)

%autosetup -n %{name}-%{version}
- %{name}-%{version} is the default already, no need to specify it here.

The "cp" and "install" statements do not preserve timestamps. Please use the "-p" options.

Please review some other packages

Comment 20 Sachidananda Urs 2017-01-10 11:44:03 UTC
> install -m 755 extras/usecases/replace-node/gluster-replace-node \
>         %{buildroot}/usr/bin
> - Do you need to make %{buildroot}/usr/bin here?, or does the earlier
> "setup.py install" command already create that directory for you?

I do run mkdir before running install.


> 
> %global _rpmfilename noarch/%{name}-%{version}-%{release}%{?dist}.rpm
> I don't think this line is needed.

I wanted the rpm to be created with version-release and dist name. 
Because by default noarch is added. For example:

gdeploy-2.0.1-3.el7rhgs.rpm
gdeploy-2.0.1-3.noarch.rpm

What is the convention?

Comment 21 Igor Gnatenko 2017-01-10 11:45:57 UTC
(In reply to Sachidananda Urs from comment #20)
> > install -m 755 extras/usecases/replace-node/gluster-replace-node \
> >         %{buildroot}/usr/bin
> > - Do you need to make %{buildroot}/usr/bin here?, or does the earlier
> > "setup.py install" command already create that directory for you?
> 
> I do run mkdir before running install.
> 
> 
> > 
> > %global _rpmfilename noarch/%{name}-%{version}-%{release}%{?dist}.rpm
> > I don't think this line is needed.
> 
> I wanted the rpm to be created with version-release and dist name. 
> Because by default noarch is added. For example:
> 
> gdeploy-2.0.1-3.el7rhgs.rpm
> gdeploy-2.0.1-3.noarch.rpm
> 
> What is the convention?
To not override RPM things.

Comment 22 Sachidananda Urs 2017-01-10 11:52:40 UTC
> Please review some other packages

I've started to do unofficial reviews:

https://bugzilla.redhat.com/show_bug.cgi?id=1402656
https://bugzilla.redhat.com/show_bug.cgi?id=1406786
https://bugzilla.redhat.com/show_bug.cgi?id=1030968

Will do more detailed reviews.

Comment 24 Sandro Bonazzola 2017-03-17 12:59:52 UTC
Ken, can you please review comment #23 changes?

Comment 25 Sandro Bonazzola 2017-07-18 07:27:56 UTC
Ken?

Comment 26 Eyal Edri 2017-08-06 09:16:34 UTC
Any update on accepting the gdeploy package? any more actions are required?

Comment 27 Niels de Vos 2017-08-08 10:41:57 UTC
Following https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews#Reviewer_not_responding and resetting the status of the review back to the defaults.

Comment #23 contains a mostly reviewed status of the package. Reviewing this should be straight forward now (Sac needs a sponsor too).

Comment 28 Ken Dreyer 2017-08-08 16:13:59 UTC
Please accept my apologies for the delay and lack of communication! That is bad.

I can continue the review or let someone else take it.

Looks like the LICENSE file should be listed as %license under %files.

Would you please use the newer %py2_build and %py2_install macros? https://fedoraproject.org/wiki/Packaging:Python

Can this package work with Python 3 instead of Python 2? Maybe it would be a good idea to add a comment to the .spec file explaining why this will not work with Python 3 if that is the case. https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3 is coming eventually. You could conditionalize py2/py3 with "%if %{?rhel} < 8" if you want to share the same .spec file across RHEL 7 and Fedora.

Comment 29 Sachidananda Urs 2017-08-08 16:41:22 UTC
(In reply to Ken Dreyer from comment #28)
> Please accept my apologies for the delay and lack of communication! That is
> bad.
> 
> I can continue the review or let someone else take it.
> 
> Looks like the LICENSE file should be listed as %license under %files.
> 
> Would you please use the newer %py2_build and %py2_install macros?
> https://fedoraproject.org/wiki/Packaging:Python
> 
> Can this package work with Python 3 instead of Python 2? Maybe it would be a
> good idea to add a comment to the .spec file explaining why this will not
> work with Python 3 if that is the case.
> https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3 is coming
> eventually. You could conditionalize py2/py3 with "%if %{?rhel} < 8" if you
> want to share the same .spec file across RHEL 7 and Fedora.

Ack! Will do that.

Comment 30 Paulo Andrade 2017-08-09 18:01:13 UTC
Taking for review.

Comment 31 Paulo Andrade 2017-08-09 18:44:30 UTC
Links are confusing.
The https://download.gluster.org/pub/gluster/gdeploy/gdeploy.spec
file is very outdated.
The actual srpm is https://download.gluster.org/pub/gluster/gdeploy/gdeploy-2.0.2-13.src.rpm

Spec from link differs from spec in srpm. Changelog is missing
from -5 to -13 in the srpm. From the link jumps to -4 to -13.

Tested downloading the src.rpm and running:
$ fedora-review -r -n gdeploy

I suggest you to install the fedora-review package, and test
yourself running:
$ fedora-review -b 1344276

This way you can see most if not all details a reviewer will
talk about :)


* Please update the bug report with matching SRPM URL and SPEC URL.
  Also make sure src.rpm spec matches spec in SPEC url.

* License does not match. There are several GPLv3+ licensed files
  in the tarball.
  Apparently, should use "License: GPLv2+ and GPLv3+"
  File gdeployrest/gdeployapi.py is GPLv3+ with incorrect FSF address.

* Documentation should be built with sphinx. Not install sources, e.g.
  in build have:
  pushd doc
    make html
  popd

* Documentation should be in a separate -doc package. It is already
  large in source format, and will be larger in html format.

* Upstream source is not available:
  https://github.com/gluster/gdeploy/archive/v2.0.2.tar.gz#/gdeploy-2.0.2.tar.gz
  Latest from github is 2.0.1.

* Please either add a %check section and run the script in the tests
  directory, or give a good reason for not to. Usually, just loading
  the python files is enough to detect issues on other architectures,
  or other "random" issues.

Comment 32 Sachidananda Urs 2017-08-11 16:09:49 UTC
(In reply to Paulo Andrade from comment #31)
> Links are confusing.
> The https://download.gluster.org/pub/gluster/gdeploy/gdeploy.spec
> file is very outdated.
> The actual srpm is
> https://download.gluster.org/pub/gluster/gdeploy/gdeploy-2.0.2-13.src.rpm


Sorry about that.

SPEC URL: http://thegaul.org/gdeploy/gdeploy.spec
SRPM URL: http://thegaul.org/gdeploy/gdeploy-2.0.2-13.src.rpm

I'll keep them consistent.

> 
> Spec from link differs from spec in srpm. Changelog is missing
> from -5 to -13 in the srpm. From the link jumps to -4 to -13.
> 

Fixed.

> Tested downloading the src.rpm and running:
> $ fedora-review -r -n gdeploy
> 
> I suggest you to install the fedora-review package, and test
> yourself running:
> $ fedora-review -b 1344276
> 

fedora-review does not report anything alarming. Except few complaints on missing shebang which I think is fine.

> This way you can see most if not all details a reviewer will
> talk about :)
> 
> 
> * Please update the bug report with matching SRPM URL and SPEC URL.
>   Also make sure src.rpm spec matches spec in SPEC url.
> 

Done. They match now.

> * License does not match. There are several GPLv3+ licensed files
>   in the tarball.
>   Apparently, should use "License: GPLv2+ and GPLv3+"
>   File gdeployrest/gdeployapi.py is GPLv3+ with incorrect FSF address.

Fixed.

> 
> * Documentation should be built with sphinx. Not install sources, e.g.
>   in build have:
>   pushd doc
>     make html
>   popd
> 

Done. This is a good idea, thanks.

> * Documentation should be in a separate -doc package. It is already
>   large in source format, and will be larger in html format.
> 

gdeploy is now split into gdeploy and gdepoy-doc packages.

> * Upstream source is not available:
>  
> https://github.com/gluster/gdeploy/archive/v2.0.2.tar.gz#/gdeploy-2.0.2.tar.
> gz
>   Latest from github is 2.0.1.

Fixed this.

> 
> * Please either add a %check section and run the script in the tests
>   directory, or give a good reason for not to. Usually, just loading
>   the python files is enough to detect issues on other architectures,
>   or other "random" issues.

The tests are not complete, they are outdated and not maintained. Plan
to fix this in future releases. Request an exception for this.

Comment 33 Paulo Andrade 2017-08-11 17:31:12 UTC
Package Review
==============

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


Issues:
=======
- Dist tag is present.


===== 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: "*No copyright* GPL (v3 or later)", "GPL (v3 or later)",
     "Unknown or generated". 333 files have unknown license. Detailed
     output of licensecheck in /home/pcpa/1344276-gdeploy/licensecheck.txt
[x]: License file installed when any subpackage combination is installed.
[!]: If the package is under multiple licenses, the licensing breakdown
     must be documented in the spec.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[x]: Package contains desktop file if it is a GUI application.
[x]: 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.
[x]: 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.
[x]: Package contains systemd file(s) if in need.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 10240 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]: 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:
[!]: Uses parallel make %{?_smp_mflags} macro.
[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 gdeploy-
     doc
[?]: 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.
[?]: 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]: 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]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[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: gdeploy-2.0.2-13.noarch.rpm
          gdeploy-doc-2.0.2-13.noarch.rpm
          gdeploy-2.0.2-13.src.rpm
gdeploy.noarch: E: wrong-script-interpreter /usr/bin/gluster-replace-node /usr/bin/env bash
gdeploy.noarch: E: script-without-shebang /usr/lib/python2.7/site-packages/ansible/modules/gdeploy/README.md
gdeploy.noarch: E: script-without-shebang /usr/lib/python2.7/site-packages/ansible/modules/gdeploy/__init__.py
gdeploy.noarch: E: script-without-shebang /usr/lib/python2.7/site-packages/ansible/plugins/callback/gdeploy.py
gdeploy.noarch: E: wrong-script-interpreter /usr/share/gdeploy/scripts/blacklist_all_disks.sh /usr/bin/env bash
gdeploy.noarch: E: wrong-script-interpreter /usr/share/gdeploy/scripts/disable-gluster-hooks.sh /usr/bin/env bash
gdeploy.noarch: E: wrong-script-interpreter /usr/share/gdeploy/scripts/disable-multipath.sh /usr/bin/env bash
gdeploy.noarch: E: wrong-script-interpreter /usr/share/gdeploy/scripts/grafton-sanity-check.sh /usr/bin/env bash
gdeploy.noarch: E: wrong-script-interpreter /usr/share/gdeploy/usecases/nuke-bricks/nuke-bricks.sh /usr/bin/env bash -u
gdeploy.noarch: E: non-executable-script /usr/share/gdeploy/usecases/nuke-bricks/nuke-bricks.sh 644 /usr/bin/env bash -u
gdeploy.noarch: E: wrong-script-interpreter /usr/share/gdeploy/usecases/replace-node/gluster-replace-node /usr/bin/env bash
gdeploy.noarch: E: wrong-script-interpreter /usr/share/gdeploy/usecases/replace-node/replace_prep.sh /usr/bin/env bash
gdeploy.noarch: W: no-manual-page-for-binary gluster-replace-node
gdeploy-doc.noarch: W: summary-not-capitalized C gdeploy documentation
gdeploy-doc.noarch: W: hidden-file-or-dir /usr/share/doc/gdeploy/html/.buildinfo
gdeploy.src: W: file-size-mismatch gdeploy-2.0.2.tar.gz = 1951206, https://github.com/gluster/gdeploy/archive/v2.0.2.tar.gz#/gdeploy-2.0.2.tar.gz = 1951712
3 packages and 0 specfiles checked; 12 errors, 4 warnings.




Rpmlint (installed packages)
----------------------------
gdeploy-doc.noarch: W: summary-not-capitalized C gdeploy documentation
gdeploy-doc.noarch: W: hidden-file-or-dir /usr/share/doc/gdeploy/html/.buildinfo
gdeploy.noarch: E: wrong-script-interpreter /usr/share/gdeploy/usecases/replace-node/gluster-replace-node /usr/bin/env bash
gdeploy.noarch: E: wrong-script-interpreter /usr/share/gdeploy/usecases/nuke-bricks/nuke-bricks.sh /usr/bin/env bash -u
gdeploy.noarch: E: non-executable-script /usr/share/gdeploy/usecases/nuke-bricks/nuke-bricks.sh 644 /usr/bin/env bash -u
gdeploy.noarch: E: script-without-shebang /usr/lib/python2.7/site-packages/ansible/modules/gdeploy/__init__.py
gdeploy.noarch: E: script-without-shebang /usr/lib/python2.7/site-packages/ansible/plugins/callback/gdeploy.py
gdeploy.noarch: E: wrong-script-interpreter /usr/share/gdeploy/scripts/grafton-sanity-check.sh /usr/bin/env bash
gdeploy.noarch: E: wrong-script-interpreter /usr/share/gdeploy/scripts/disable-multipath.sh /usr/bin/env bash
gdeploy.noarch: E: wrong-script-interpreter /usr/share/gdeploy/usecases/replace-node/replace_prep.sh /usr/bin/env bash
gdeploy.noarch: E: wrong-script-interpreter /usr/share/gdeploy/scripts/disable-gluster-hooks.sh /usr/bin/env bash
gdeploy.noarch: E: wrong-script-interpreter /usr/bin/gluster-replace-node /usr/bin/env bash
gdeploy.noarch: E: wrong-script-interpreter /usr/share/gdeploy/scripts/blacklist_all_disks.sh /usr/bin/env bash
gdeploy.noarch: E: script-without-shebang /usr/lib/python2.7/site-packages/ansible/modules/gdeploy/README.md
gdeploy.noarch: W: no-manual-page-for-binary gluster-replace-node
2 packages and 0 specfiles checked; 12 errors, 3 warnings.



Requires
--------
gdeploy-doc (rpmlib, GLIBC filtered):

gdeploy (rpmlib, GLIBC filtered):
    /usr/bin/env
    /usr/bin/python
    /usr/bin/python2
    PyYAML
    ansible
    lvm2
    python(abi)
    python2



Provides
--------
gdeploy-doc:
    gdeploy-doc

gdeploy:
    gdeploy



Source checksums
----------------
https://github.com/gluster/gdeploy/archive/v2.0.2.tar.gz#/gdeploy-2.0.2.tar.gz :
  CHECKSUM(SHA256) this package     : cf6c600ba97fd32c183e08efa2c96ed9762c5523cf89372662ce0bc81e61ca8c
  CHECKSUM(SHA256) upstream package : 58088f0c8dc0d2496f7d8a52bfb4156b874927be68b849e8a63ed6e659e4d44b
However, diff -r shows no differences


Generated by fedora-review 0.6.1 (f03e4e7) last change: 2016-05-02
Command line :/usr/bin/fedora-review -b 1344276
Buildroot used: fedora-24-x86_64
Active plugins: Python, Generic, Shell-api
Disabled plugins: Java, C/C++, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP
Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6

---

  AFAIK there is no policy to the format you used for the doc
subpackage, that is, %package and %files in a "single chunk".
Personally, I used this pattern before for some packages with
a lot of subpackages.

  I believe the package is good and most issues have been reasoned,
but will ask for two extra changes before approving the package and
sponsoring you:

o Use the same tarball in the srpm and upstream. I believe the 
  upstream tarball was regenerated, thus difference checksum, as
  contents are the same.
o Do a minor license breakdown about the installed GPLv3 files.
  https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios
  Otherwise, it should not be required to also install a GPLv3 license file.

Comment 34 Sachidananda Urs 2017-08-13 07:38:41 UTC
>   I believe the package is good and most issues have been reasoned,
> but will ask for two extra changes before approving the package and
> sponsoring you:
> 
> o Use the same tarball in the srpm and upstream. I believe the 
>   upstream tarball was regenerated, thus difference checksum, as
>   contents are the same.

Ack! Will do that.

> o Do a minor license breakdown about the installed GPLv3 files.
>  
> https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/
> LicensingGuidelines#Multiple_Licensing_Scenarios
>   Otherwise, it should not be required to also install a GPLv3 license file.

Paulo, I need a bit of help here, regarding the license. The LICENSE file
says GPLv2 however none of the source files actually are version 2. This mismatch
has happened somewhere earlier in the project because it was overlooked.

I would like to replace the GPLv2 LICENSE file with v3 and continue with v3 in
future. Can you advice if it is fine?

Comment 35 Paulo Andrade 2017-08-14 13:41:00 UTC
  The easiest approach would be to make a new release, and
change the files to use GPLv3+. But you would need to ask
all contributors to agree to it. Likely just one line
replacement of /2/3/ for the files under GPLv2+.

  Files without a license header use the LICENSE file. But
IANAL, and this could be contested. But I do not suggest
patching the files to add a license header, as most if not
all are kind of trivial or non distributed files.

Comment 36 Sachidananda Urs 2017-08-15 11:43:14 UTC
(In reply to Paulo Andrade from comment #35)
>   The easiest approach would be to make a new release, and
> change the files to use GPLv3+. But you would need to ask
> all contributors to agree to it. Likely just one line
> replacement of /2/3/ for the files under GPLv2+.

I will make a new release and change the files to GPLv3+. I spoke
to the contributor and have consent. Will upload the new spec and
sprm file. Thanks again.

> 
>   Files without a license header use the LICENSE file. But
> IANAL, and this could be contested. But I do not suggest
> patching the files to add a license header, as most if not
> all are kind of trivial or non distributed files.

Comment 37 Sachidananda Urs 2017-08-16 09:39:18 UTC
I've fixed both the changes mentioned in Comment #35

SPEC URL: http://thegaul.org/gdeploy/gdeploy.spec
SRPM URL: http://thegaul.org/gdeploy/gdeploy-2.0.2-14.src.rpm

* Now the md5sums match
* LICENSE file updated

Comment 38 Paulo Andrade 2017-08-16 16:39:13 UTC
Package is approved!

  Before pushing it, please add a changelog entry for
-14 release and check/confirm if *.py under
/usr/lib/python2.7/site-packages/ansible/plugins
should really be executable (looks like not...)

  Please confirm your FAS account name so i can
proceed to sponsor you.

Comment 39 Sachidananda Urs 2017-08-16 18:23:40 UTC
(In reply to Paulo Andrade from comment #38)
> Package is approved!
> 
>   Before pushing it, please add a changelog entry for
> -14 release and

My mistake. Fixed the latest commit.

 check/confirm if *.py under
> /usr/lib/python2.7/site-packages/ansible/plugins
> should really be executable (looks like not...)
> 

Yep, does not really need the execute permission. 
I've updated the spec, now installs the file with mode 644. 

>   Please confirm your FAS account name so i can
> proceed to sponsor you.

My FAS account name is: sac

Comment 40 Paulo Andrade 2017-08-17 14:27:26 UTC
Welcome as a Fedora Packager!

I suggest following the procedures starting at https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Add_Package_to_Source_Code_Management_.28SCM.29_system_and_Set_Owner
to add the package.

I also suggest using your gmail account for Fedora bugzilla
issues, as it is the email associated with your FAS account.

If you have any issues feel free to ping me in irc, nickname
pcpa, or send me an email.

Comment 41 Parag AN(पराग) 2017-08-17 14:37:15 UTC
I am glad that this has finally finished.

Comment 42 Sachidananda Urs 2017-08-18 06:47:27 UTC
(In reply to Paulo Andrade from comment #40)
> Welcome as a Fedora Packager!
> 
> I suggest following the procedures starting at
> https://fedoraproject.org/wiki/
> Join_the_package_collection_maintainers#Add_Package_to_Source_Code_Management
> _.28SCM.29_system_and_Set_Owner
> to add the package.
> 
> I also suggest using your gmail account for Fedora bugzilla
> issues, as it is the email associated with your FAS account.

Sure.

> 
> If you have any issues feel free to ping me in irc, nickname
> pcpa, or send me an email.

Thank you. I've raised a request to add the package.

Comment 43 Gwyn Ciesla 2017-08-18 13:49:31 UTC
(fedrepo-req-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/gdeploy

Comment 44 Gwyn Ciesla 2017-08-18 13:49:54 UTC
(fedrepo-req-admin):  The sync took place when you logged in the first time.

Comment 45 Fedora Update System 2017-09-01 11:55:44 UTC
gdeploy-2.0.2-14.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-388358a44d

Comment 46 Fedora Update System 2017-09-01 12:54:00 UTC
gdeploy-2.0.2-14.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-948d6d6dfc

Comment 47 Fedora Update System 2017-09-09 23:51:46 UTC
gdeploy-2.0.2-14.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Comment 48 Fedora Update System 2017-09-10 04:52:23 UTC
gdeploy-2.0.2-14.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.