Bug 1287846

>%{!?__python2: %global __python2 %__python}
>%{!?python2_sitelib: %global python2_sitelib %(%{__python2} -c "from >distutils.sysconfig import get_python_lib; print(get_python_lib())")}

You don't need to define __python2, python2_sitelib macros unless you want package in RHEL 6 and older.

>%define name lib389
>%define version 1.0.1
>%define prerel 1

These are redundant as well.

Do you want build lib389 in RHEL 5?

(In reply to Antonio Trande from comment #1)
> >%{!?__python2: %global __python2 %__python}
> >%{!?python2_sitelib: %global python2_sitelib %(%{__python2} -c "from >distutils.sysconfig import get_python_lib; print(get_python_lib())")}
> 
> You don't need to define __python2, python2_sitelib macros unless you want
> package in RHEL 6 and older.

I was just following the rpmdevtool template, I will remove these lines.

> 
> >%define name lib389
> >%define version 1.0.1
> >%define prerel 1
> 
> These are redundant as well.
> 
> Do you want build lib389 in RHEL 5?

No, RHEL7 and up

$ rpmlint ./lib389-1.0.1-1.fc22.noarch.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint ./lib389-1.0.1-1.fc22.src.rpm 
lib389.src: W: file-size-mismatch lib389-1.0.1-1.tar.bz2 = 103561, http://port389.org/binaries/lib389-1.0.1-1.tar.bz2 = 9568
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

The files are the same size, so I think this is a false positive.

I have also uploaded new versions of the spec file and source rpm:

http://www.port389.org/binaries/lib389.spec
http://www.port389.org/binaries/lib389-1.0.1-1.fc22.src.rpm

(In reply to mreynolds from comment #2)
> (In reply to Antonio Trande from comment #1)
> > >%{!?__python2: %global __python2 %__python}
> > >%{!?python2_sitelib: %global python2_sitelib %(%{__python2} -c "from >distutils.sysconfig import get_python_lib; print(get_python_lib())")}
> > 
> > You don't need to define __python2, python2_sitelib macros unless you want
> > package in RHEL 6 and older.
> 
> I was just following the rpmdevtool template, I will remove these lines.
> 
> > 
> > >%define name lib389
> > >%define version 1.0.1
> > >%define prerel 1
> > 
> > These are redundant as well.
> > 
> > Do you want build lib389 in RHEL 5?
> 
> No, RHEL7 and up

Okay.

>%define prerel 1

Still redundant.

>BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
>Prefix: %{_prefix}
>Vendor: Red Hat Inc. <389-devel.org>
>rm -rf $RPM_BUILD_ROOT
>Full %clean section
>%defattr(-,root,root,-)

Set automatically; please, remove them.

- Use %{__python2} macro in %build and %install

- LICENSE must be tagged with %license

- Use %{python2_sitelib}/*, not %{python_sitelib}/*

General Guidelines: http://fedoraproject.org/wiki/Packaging:Guidelines
Guidelines for Python code: http://fedoraproject.org/wiki/Packaging:Python

(In reply to Antonio Trande from comment #4)
> (In reply to mreynolds from comment #2)
> > (In reply to Antonio Trande from comment #1)
> > > >%{!?__python2: %global __python2 %__python}
> > > >%{!?python2_sitelib: %global python2_sitelib %(%{__python2} -c "from >distutils.sysconfig import get_python_lib; print(get_python_lib())")}
> > > 
> > > You don't need to define __python2, python2_sitelib macros unless you want
> > > package in RHEL 6 and older.
> > 
> > I was just following the rpmdevtool template, I will remove these lines.
> > 
> > > 
> > > >%define name lib389
> > > >%define version 1.0.1
> > > >%define prerel 1
> > > 
> > > These are redundant as well.
> > > 
> > > Do you want build lib389 in RHEL 5?
> > 
> > No, RHEL7 and up
> 
> Okay.
> 
> >%define prerel 1
> 
> Still redundant.

Why?  Please explain.  Since "release" gets %{?dist} I can not reuse "release" for the source code version/layout.  Using "prerel", or some other variable, would make future maintenance easier since there are several places that reference it.  

Anyway, I just removed prerel and manually added the "1" to the various places in the spec file.

> 
> >BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
> >Prefix: %{_prefix}
> >Vendor: Red Hat Inc. <389-devel.org>
> >rm -rf $RPM_BUILD_ROOT
> >Full %clean section
> >%defattr(-,root,root,-)
> 
> Set automatically; please, remove them.
> 
> - Use %{__python2} macro in %build and %install

I thought you asked me to remove that?

> 
> - LICENSE must be tagged with %license

Sorry I missed this.

> 
> - Use %{python2_sitelib}/*, not %{python_sitelib}/*

Again I thought you wanted me to remove these.

> 
> General Guidelines: http://fedoraproject.org/wiki/Packaging:Guidelines

Note - these docs say to follow(as closely as possible) the rpmdevtool templates for spec files - these are obviously now outdated as you pointed out  various issues in my spec file which directly came from these templates.

> Guidelines for Python code: http://fedoraproject.org/wiki/Packaging:Python

Yes I've read these, but I was trying to respond to your suggestions.  Clearly I misunderstood your comments.  I apologize.

I've uploaded the new spec file, and srpm. (same rpmlint results)

Thanks again for reviewing this!

(In reply to mreynolds from comment #5)
> (In reply to Antonio Trande from comment #4)
> > (In reply to mreynolds from comment #2)
> > > (In reply to Antonio Trande from comment #1)
> > > > >%{!?__python2: %global __python2 %__python}
> > > > >%{!?python2_sitelib: %global python2_sitelib %(%{__python2} -c "from >distutils.sysconfig import get_python_lib; print(get_python_lib())")}
> > > > 
> > > > You don't need to define __python2, python2_sitelib macros unless you want
> > > > package in RHEL 6 and older.
> > > 
> > > I was just following the rpmdevtool template, I will remove these lines.
> > > 
> > > > 
> > > > >%define name lib389
> > > > >%define version 1.0.1
> > > > >%define prerel 1
> > > > 
> > > > These are redundant as well.
> > > > 
> > > > Do you want build lib389 in RHEL 5?
> > > 
> > > No, RHEL7 and up
> > 
> > Okay.
> > 
> > >%define prerel 1
> > 
> > Still redundant.
> 
> Why?  Please explain.  Since "release" gets %{?dist} I can not reuse
> "release" for the source code version/layout.  Using "prerel", or some other
> variable, would make future maintenance easier since there are several
> places that reference it.

I don't understand your need to make a 'prerel' macro when you can directly set Release as 1%{?dist}.

Can you do a example?

> 
> > 
> > >BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
> > >Prefix: %{_prefix}
> > >Vendor: Red Hat Inc. <389-devel.org>
> > >rm -rf $RPM_BUILD_ROOT
> > >Full %clean section
> > >%defattr(-,root,root,-)
> > 
> > Set automatically; please, remove them.
> > 
> > - Use %{__python2} macro in %build and %install
> 
> I thought you asked me to remove that?
> > 
> > - Use %{python2_sitelib}/*, not %{python_sitelib}/*
> 
> Again I thought you wanted me to remove these.
> 

I asked you not to define them unless your package is for RHEL <= 6 too.
 
> > 
> > General Guidelines: http://fedoraproject.org/wiki/Packaging:Guidelines
> 
> Note - these docs say to follow(as closely as possible) the rpmdevtool
> templates for spec files - these are obviously now outdated as you pointed
> out  various issues in my spec file which directly came from these templates.

'rpmdevtools' is updated.

$ rpmdev-newspec -r 4.13 test.spec

(where 4.13 is current RPM release in Fedora) makes a very clear and minimal spec file.

> 
> > Guidelines for Python code: http://fedoraproject.org/wiki/Packaging:Python
> 
> Yes I've read these, but I was trying to respond to your suggestions. 
> Clearly I misunderstood your comments.  I apologize.
> 

No problem; i hope to be as possible as clear by using English.

> > 
> > Why?  Please explain.  Since "release" gets %{?dist} I can not reuse
> > "release" for the source code version/layout.  Using "prerel", or some other
> > variable, would make future maintenance easier since there are several
> > places that reference it.
> 
> I don't understand your need to make a 'prerel' macro when you can directly
> set Release as 1%{?dist}.
> 
> Can you do a example?

Sure, so the "full" version is lib389-1.0.1-1

The source code is named and packaged this way (just like what we do in 389-ds-base), but when I used %{?dist} it changes to:  lib389-1.0.1-1.f22 for example.

This is not how the source is laid out(withe dist extension), thus I can not use it in most of the spec file.  Then when I do my next minor release it will be: lib389-1.0.1-2.  Using a macro I only need to bump this number up in one place - not in three places. 

It's no big deal, I just manually set it where it's needed (see my latest spec file I updated earlier)


> > > 
> > > General Guidelines: http://fedoraproject.org/wiki/Packaging:Guidelines
> > 
> > Note - these docs say to follow(as closely as possible) the rpmdevtool
> > templates for spec files - these are obviously now outdated as you pointed
> > out  various issues in my spec file which directly came from these templates.
> 
> 'rpmdevtools' is updated.
> 
> $ rpmdev-newspec -r 4.13 test.spec

I was referring to:  /etc/rpmdevtools/spectemplate-python.spec

> 
> (where 4.13 is current RPM release in Fedora) makes a very clear and minimal
> spec file.

(In reply to mreynolds from comment #7)
> > > 
> > > Why?  Please explain.  Since "release" gets %{?dist} I can not reuse
> > > "release" for the source code version/layout.  Using "prerel", or some other
> > > variable, would make future maintenance easier since there are several
> > > places that reference it.
> > 
> > I don't understand your need to make a 'prerel' macro when you can directly
> > set Release as 1%{?dist}.
> > 
> > Can you do a example?
> 
> Sure, so the "full" version is lib389-1.0.1-1

You refer to full "upstream" version, i think.

> 
> The source code is named and packaged this way (just like what we do in
> 389-ds-base), but when I used %{?dist} it changes to:  lib389-1.0.1-1.f22
> for example.
> 
> This is not how the source is laid out(withe dist extension), thus I can not
> use it in most of the spec file.  Then when I do my next minor release it
> will be: lib389-1.0.1-2.  Using a macro I only need to bump this number up
> in one place - not in three places.

Release tag in a SPEC file is a number incremented when you rebuild a package or do some changes; sometimes it's also occasionally upped by automated tools, so i guess you cannot keep the Release number syncronized with the release number of upstream in any case.

http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Release_Tag
http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs

>BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
>Prefix: %{_prefix}
>Vendor: Red Hat Inc. <389-devel.org>
>rm -rf $RPM_BUILD_ROOT
>Full %clean section
>%defattr(-,root,root,-)

These lines are useless.

Upstream ticket:

https://fedorahosted.org/389/ticket/48358

Updated spec and srpm have been updated.

Thanks,
Mark

(In reply to mreynolds from comment #10)
> Updated spec and srpm have been updated.
> 
> Thanks,
> Mark

Your package cannot be built without the packages required for building. It needs 'python2-devel' at least.

Test your src package on 'koji' or with 'mock':

https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds
https://fedoraproject.org/wiki/Using_the_Koji_build_system

Also, get used to update the %changelog when you modify the SPEC file.
http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs

(In reply to Antonio Trande from comment #11)
> (In reply to mreynolds from comment #10)
> > Updated spec and srpm have been updated.
> > 
> > Thanks,
> > Mark
> 
> Your package cannot be built without the packages required for building. It
> needs 'python2-devel' at least.

Okay, yeah this needed some work (BuildRequires) for the mock build to success.  

> 
> Test your src package on 'koji' or with 'mock':
> 
> https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds
> https://fedoraproject.org/wiki/Using_the_Koji_build_system
> 
> Also, get used to update the %changelog when you modify the SPEC file.
> http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs

I haven't been updating the changelog since this has yet to be approved.  I was only going to update it with every new respin. Do you want me to update it with every change we are making now?

Uploaded new spec file/srpm

Thanks,
Mark

(In reply to mreynolds from comment #12)
> (In reply to Antonio Trande from comment #11)
> > (In reply to mreynolds from comment #10)
> > > Updated spec and srpm have been updated.
> > > 
> > > Thanks,
> > > Mark
> > 
> > Your package cannot be built without the packages required for building. It
> > needs 'python2-devel' at least.
> 
> Okay, yeah this needed some work (BuildRequires) for the mock build to
> success.  
> 
> > 
> > Test your src package on 'koji' or with 'mock':
> > 
> > https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds
> > https://fedoraproject.org/wiki/Using_the_Koji_build_system
> > 
> > Also, get used to update the %changelog when you modify the SPEC file.
> > http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs
> 
> I haven't been updating the changelog since this has yet to be approved.  I
> was only going to update it with every new respin. Do you want me to update
> it with every change we are making now?

It would be better

> 
> Uploaded new spec file/srpm
> 
> Thanks,
> Mark

Command for testing considers downloading of 'python-krbV' that is already provided in Fedora. 'setup.py' must use that one in Fedora. 

+ /usr/bin/python2 setup.py test
running test
Searching for python-krbV
Reading https://pypi.python.org/simple/python-krbV/
Best match: python-krbV 1.0.90
Downloading https://pypi.python.org/packages/source/p/python-krbV/python-krbV-1.0.90.tar.bz2#md5=77758e1bed2387636ca1989f1d122693
Processing python-krbV-1.0.90.tar.bz2
Writing /tmp/easy_install-2QLVGE/python-krbV-1.0.90/setup.cfg
Running python-krbV-1.0.90/setup.py -q bdist_egg --dist-dir /tmp/easy_install-2QLVGE/python-krbV-1.0.90/egg-dist-tmp-6Ueu61
krb5module.c: In function 'Context_cc_default':
...

Also, tests are not run:

> Ran 0 tests in 0.000s

- Sources used to build the package does not match the upstream source, as provided in the spec URL.

Source checksums
----------------
http://port389.org/binaries/lib389-1.0.1-1.tar.bz2 :
  CHECKSUM(SHA256) this package     : 96c0648135fd795e3de286d2095af01ac6462556cc1f6dc5ded29b782155b0cf
  CHECKSUM(SHA256) upstream package : a9e65e0c788e7b2c8f0331c51f9fdc7df0b3459c70c80bde99750d14cbff0403

> Command for testing considers downloading of 'python-krbV' that is already
> provided in Fedora. 'setup.py' must use that one in Fedora. 

I will remove the requirement for python-krbV

> 
> + /usr/bin/python2 setup.py test
> running test
> Searching for python-krbV
> Reading https://pypi.python.org/simple/python-krbV/
> Best match: python-krbV 1.0.90
> Downloading
> https://pypi.python.org/packages/source/p/python-krbV/python-krbV-1.0.90.tar.
> bz2#md5=77758e1bed2387636ca1989f1d122693
> Processing python-krbV-1.0.90.tar.bz2
> Writing /tmp/easy_install-2QLVGE/python-krbV-1.0.90/setup.cfg
> Running python-krbV-1.0.90/setup.py -q bdist_egg --dist-dir
> /tmp/easy_install-2QLVGE/python-krbV-1.0.90/egg-dist-tmp-6Ueu61
> krb5module.c: In function 'Context_cc_default':
> ...
> 
> Also, tests are not run:
> 
> > Ran 0 tests in 0.000s

I'm not sure what this is.  I do not see this in my rpmbuild or mock output.  I know that the %check section is being performed.  Is there something else?

> 
> - Sources used to build the package does not match the upstream source, as
> provided in the spec URL.
> 
> Source checksums
> ----------------
> http://port389.org/binaries/lib389-1.0.1-1.tar.bz2 :
>   CHECKSUM(SHA256) this package     :
> 96c0648135fd795e3de286d2095af01ac6462556cc1f6dc5ded29b782155b0cf
>   CHECKSUM(SHA256) upstream package :
> a9e65e0c788e7b2c8f0331c51f9fdc7df0b3459c70c80bde99750d14cbff0403

I noticed this before when running rpmlint - but the sources were the same.  I wonder if its an issue with port389.org?  I will investigate...

Created attachment 1102297 [details]
simplify topdir usage in spec file

> %setup -qc
> mv %{name}-%{version}-1 src_root

> %build
> pushd src_root

> %license src_root/LICENSE
> %doc src_root/README

This is overly complicated. What's the reason for doing it like this and moving the source topdir to a custom src_root?

Note that rpmbuild enters the topdir _automatically_ for every spec section, provided that it knows what the dir's name is.

What's the reason for appending -1 to the upstream version anyway? It can be made to work with rpmbuild, see the attached patch, but as this dubious -1 will never match the package %release, it isn't helpful.

Btw, all Python modules in Fedora's package collection are named python-foo, following the %parent-%child naming guidelines for Python add-ons:

  https://fedoraproject.org/wiki/Packaging:NamingGuidelines

There used to be an exception for Python modules that contain "py" in the name somewhere, but that exception has been dropped a few years ago.

(In reply to Michael Schwendt from comment #15)
> Created attachment 1102297 [details]
> simplify topdir usage in spec file
> 
> > %setup -qc
> > mv %{name}-%{version}-1 src_root
> 
> > %build
> > pushd src_root
> 
> > %license src_root/LICENSE
> > %doc src_root/README
> 
> This is overly complicated. What's the reason for doing it like this and
> moving the source topdir to a custom src_root?

I was just following the packaging guidelines which said to use the rpmdevtools template:  /etc/rpmdevtools/spectemplate-python.spec  

I now wish I never used this template because I've had to undo almost everything from it

> 
> Note that rpmbuild enters the topdir _automatically_ for every spec section,
> provided that it knows what the dir's name is.
> 
> What's the reason for appending -1 to the upstream version anyway? It can be
> made to work with rpmbuild, see the attached patch, but as this dubious -1
> will never match the package %release, it isn't helpful.

Thank you the patch works great, and it much simpler.  Again, I was just trying to follow the guidelines and use the recommended template.  It was problematic to being with, which is why I did/hack things the way I did.

Also, I have now changed the package name:

Spec URL: http://www.port389.org/binaries/python-lib389.spec
SRPM URL: http://www.port389.org/binaries/python-lib389-1.0.1-1.fc22.src.rpm

I'm still stumped why rpmlint is complaining that the source packages are not the same size:

    $ rpmlint ./python-lib389-1.0.1-1.fc22.src.rpm 
    python-lib389.src: W: file-size-mismatch python-lib389-1.0.1-1.tar.bz2 =
    103613, http://port389.org/binaries/python-lib389-1.0.1-1.tar.bz2 = 9568
    1 packages and 0 specfiles checked; 0 errors, 1 warnings.

I have even re-downloaded(from the openshift site) the source file to the SOURCES directory.  They should be the same, yet rpmlint complains.

(In reply to mreynolds from comment #14)
> > Command for testing considers downloading of 'python-krbV' that is already
> > provided in Fedora. 'setup.py' must use that one in Fedora. 
> 
> I will remove the requirement for python-krbV
> 
> > 
> > + /usr/bin/python2 setup.py test
> > running test
> > Searching for python-krbV
> > Reading https://pypi.python.org/simple/python-krbV/
> > Best match: python-krbV 1.0.90
> > Downloading
> > https://pypi.python.org/packages/source/p/python-krbV/python-krbV-1.0.90.tar.
> > bz2#md5=77758e1bed2387636ca1989f1d122693
> > Processing python-krbV-1.0.90.tar.bz2
> > Writing /tmp/easy_install-2QLVGE/python-krbV-1.0.90/setup.cfg
> > Running python-krbV-1.0.90/setup.py -q bdist_egg --dist-dir
> > /tmp/easy_install-2QLVGE/python-krbV-1.0.90/egg-dist-tmp-6Ueu61
> > krb5module.c: In function 'Context_cc_default':
> > ...
> > 
> > Also, tests are not run:
> > 
> > > Ran 0 tests in 0.000s
> 
> I'm not sure what this is.  I do not see this in my rpmbuild or mock output.
> I know that the %check section is being performed.  Is there something else?
> 

See build log here:
http://fpaste.org/297491/

At line #283 --> usr/bin/python2 setup.py test
#288, python-krbV is downloaded
#354, pytest is downloaded
#364, py is downloaded
#381, Ran 0 tests in 0.000s

No tests performed and 3 package downloded but already provided for building.

> > 
> > - Sources used to build the package does not match the upstream source, as
> > provided in the spec URL.
> > 
> > Source checksums
> > ----------------
> > http://port389.org/binaries/lib389-1.0.1-1.tar.bz2 :
> >   CHECKSUM(SHA256) this package     :
> > 96c0648135fd795e3de286d2095af01ac6462556cc1f6dc5ded29b782155b0cf
> >   CHECKSUM(SHA256) upstream package :
> > a9e65e0c788e7b2c8f0331c51f9fdc7df0b3459c70c80bde99750d14cbff0403
> 
> I noticed this before when running rpmlint - but the sources were the same. 
> I wonder if its an issue with port389.org?  I will investigate...

How did you created your src-rpm?

(In reply to Antonio Trande from comment #18)

> > > 
> > > Also, tests are not run:
> > > 
> > > > Ran 0 tests in 0.000s
> > 
> > I'm not sure what this is.  I do not see this in my rpmbuild or mock output.
> > I know that the %check section is being performed.  Is there something else?
> > 
> 
> See build log here:
> http://fpaste.org/297491/
> 
> At line #283 --> usr/bin/python2 setup.py test
> #288, python-krbV is downloaded
> #354, pytest is downloaded
> #364, py is downloaded
> #381, Ran 0 tests in 0.000s
> 
> No tests performed and 3 package downloded but already provided for building.

Yeah I don't have any of this output when I do my mock build:

http://fpaste.org/297505/52367144/

Perhaps its an issue between f22 and f24?  Either way I'm not sure how to "fix" this.

> 
> > > 
> > > - Sources used to build the package does not match the upstream source, as
> > > provided in the spec URL.
> > > 
> > > Source checksums
> > > ----------------
> > > http://port389.org/binaries/lib389-1.0.1-1.tar.bz2 :
> > >   CHECKSUM(SHA256) this package     :
> > > 96c0648135fd795e3de286d2095af01ac6462556cc1f6dc5ded29b782155b0cf
> > >   CHECKSUM(SHA256) upstream package :
> > > a9e65e0c788e7b2c8f0331c51f9fdc7df0b3459c70c80bde99750d14cbff0403
> > 
> > I noticed this before when running rpmlint - but the sources were the same. 
> > I wonder if its an issue with port389.org?  I will investigate...
> 
> How did you created your src-rpm?

I download the source tarball and place it in the SOURCES directory, then I run:

rpmbuild --define "_topdir `pwd`" -ba ~/source/lib389/python-lib389.spec

(In reply to mreynolds from comment #19)
> (In reply to Antonio Trande from comment #18)
> 
> > > > 
> > > > Also, tests are not run:
> > > > 
> > > > > Ran 0 tests in 0.000s
> > > 
> > > I'm not sure what this is.  I do not see this in my rpmbuild or mock output.
> > > I know that the %check section is being performed.  Is there something else?
> > > 
> > 
> > See build log here:
> > http://fpaste.org/297491/
> > 
> > At line #283 --> usr/bin/python2 setup.py test
> > #288, python-krbV is downloaded
> > #354, pytest is downloaded
> > #364, py is downloaded
> > #381, Ran 0 tests in 0.000s
> > 
> > No tests performed and 3 package downloded but already provided for building.
> 
> Yeah I don't have any of this output when I do my mock build:
> 
> http://fpaste.org/297505/52367144/
> 
> Perhaps its an issue between f22 and f24?  Either way I'm not sure how to
> "fix" this.
> 

See line #481.
sudo mock -r fedora-22-x86_64 --rebuild python-lib389-1.0.1-1.fc22.src.rpm ?

> > 
> > > > 
> > > > - Sources used to build the package does not match the upstream source, as
> > > > provided in the spec URL.
> > > > 
> > > > Source checksums
> > > > ----------------
> > > > http://port389.org/binaries/lib389-1.0.1-1.tar.bz2 :
> > > >   CHECKSUM(SHA256) this package     :
> > > > 96c0648135fd795e3de286d2095af01ac6462556cc1f6dc5ded29b782155b0cf
> > > >   CHECKSUM(SHA256) upstream package :
> > > > a9e65e0c788e7b2c8f0331c51f9fdc7df0b3459c70c80bde99750d14cbff0403
> > > 
> > > I noticed this before when running rpmlint - but the sources were the same. 
> > > I wonder if its an issue with port389.org?  I will investigate...
> > 
> > How did you created your src-rpm?
> 
> I download the source tarball and place it in the SOURCES directory, then I
> run:
> 
> rpmbuild --define "_topdir `pwd`" -ba ~/source/lib389/python-lib389.spec

See https://fedoraproject.org/wiki/How_to_create_an_RPM_package
Please, read carefully how to use 'rpmbuild'.

(In reply to Antonio Trande from comment #20)
> 
> See line #481.

Ah, I had python-krbV listed in my setup.py file.  Do I need to also remove pytest?

And I still don't see "Ran 0 tests in 0.000s" in my output.

> sudo mock -r fedora-22-x86_64 --rebuild python-lib389-1.0.1-1.fc22.src.rpm ?
> 
> > > 
> > > 
> > > How did you created your src-rpm?
> > 
> > I download the source tarball and place it in the SOURCES directory, then I
> > run:
> > 
> > rpmbuild --define "_topdir `pwd`" -ba ~/source/lib389/python-lib389.spec
> 
> See https://fedoraproject.org/wiki/How_to_create_an_RPM_package
> Please, read carefully how to use 'rpmbuild'.

I'll check this out later this afternoon.

(In reply to mreynolds from comment #21)
> (In reply to Antonio Trande from comment #20)
> > 
> > See line #481.
> 
> Ah, I had python-krbV listed in my setup.py file.  Do I need to also remove
> pytest?
> 

None package should be downloaded during package building (see http://fedoraproject.org/wiki/Packaging:Python#Reviewer_checklist).

Even because download wouldn't permitted in koji.

pbrobinson's scratch build of 389-admin-console?#4c0bc134ccbaf5009b730f4d8622b201fa48208f for epel7-archbootstrap and git://pkgs.fedoraproject.org/389-admin-console?#4c0bc134ccbaf5009b730f4d8622b201fa48208f failed http://koji.fedoraproject.org/koji/taskinfo?taskID=12089193

pbrobinson's scratch build of 389-ds-console?#0044db717ad3da5a93b57705c530259de32f1e07 for epel7-archbootstrap and git://pkgs.fedoraproject.org/389-ds-console?#0044db717ad3da5a93b57705c530259de32f1e07 failed http://koji.fedoraproject.org/koji/taskinfo?taskID=12089209

pbrobinson's scratch build of 389-admin-console?#4c0bc134ccbaf5009b730f4d8622b201fa48208f for epel7-archbootstrap and git://pkgs.fedoraproject.org/389-admin-console?#4c0bc134ccbaf5009b730f4d8622b201fa48208f completed http://koji.fedoraproject.org/koji/taskinfo?taskID=12096432

Okay I believe everything is correct now.  There are no more dependencies being downloaded during the build process.  The spec file complies with the checklist.  I have everything being built under ~/rpmbuild

I built the RPM in ~/rpmbuild/SPEC

[mareynol@ldap SPECS]$ rpmbuild -ba ./python-lib389.spec 

But rpmlint on the srpm file still complains (warns) that the source on port389.org and SOURCES does not match.  They are the same though, so I'm assuming this is false warning.  Even when I download the source file it is the same size as the file in SOURCES.  So I'm not sure what's going on with the warning, or how to fix the warning.

Spec URL: http://www.port389.org/binaries/python-lib389.spec
SRPM URL: http://www.port389.org/binaries/python-lib389-1.0.1-1.fc22.src.rpm

- Why have you added these lines?

>%package -n python2-lib389
>Summary: %{sum}
>%{?python_provide:%python_provide python2-lib389}
>
>%description -n python2-lib389
>%{desc}

Kee only this one:
%{?python_provide:%python_provide python2-lib389}

- I tried to run tests in this way

%check
export PYTHONPATH=$RPM_BUILD_ROOT%{python2_sitelib}
pytest -v -t build/lib/lib389/tests

but just now I suspect that they're made to work differently instead:

http://www.port389.org/docs/389ds/FAQ/upstream-test-framework.html#basic-setup-and-testing

sagitter's scratch build of python-lib389-1.0.1-1.fc23.src.rpm for epel7 failed http://koji.fedoraproject.org/koji/taskinfo?taskID=12101590

(In reply to Antonio Trande from comment #27)
> - Why have you added these lines?


I was following the checklist:

Must: If you build for a single python runtime you must add %python_provide python-$module so that the current default python is provided from the unversioned python package. 

Above this comment on the same page it gives an example:

=============================================
%package -n python2-%{srcname}
Summary:        %{sum}
%{?python_provide:%python_provide python2-%{srcname}}

%description -n python2-%{srcname}
An python module which provides a convenient example.
============================================


> 
> >%package -n python2-lib389
> >Summary: %{sum}
> >%{?python_provide:%python_provide python2-lib389}
> >
> >%description -n python2-lib389
> >%{desc}
> 
> Kee only this one:
> %{?python_provide:%python_provide python2-lib389}

This works fine, and I've updated/uploaded the spec file.  Thanks

> 
> - I tried to run tests in this way
> 
> %check
> export PYTHONPATH=$RPM_BUILD_ROOT%{python2_sitelib}
> pytest -v -t build/lib/lib389/tests
> 
> but just now I suspect that they're made to work differently instead:
> 
> http://www.port389.org/docs/389ds/FAQ/upstream-test-framework.html#basic-
> setup-and-testing

The "tests" we have written are designed to be run against a running 389 Directory Server.  This doesn't seem like something that can be tested/run during rpm building.  So basically there is nothing to test, or should I say we don't have any tests that can be run during rpm packaging.

UPDATE

As for the epel7 build failure that was just reported, I have just updated/uploaded the spec file to include python-setuptools.  This was not needed for my mock builds, but it also does not cause any harm by adding it(no downloads, etc)

- Diff spec file in url and in SRPM

- There is still something wrong with source archives (they don't seem regular); have you changed that one hosted on http://port389.org/binaries?

Source checksums
----------------
http://port389.org/binaries/python-lib389-1.0.1-1.tar.bz2 :
  CHECKSUM(SHA256) this package     : f7fda4d02fc50d91389c233c72df17f2214a98082a93d9754cdac9124be0edf6
  CHECKSUM(SHA256) upstream package : a9e65e0c788e7b2c8f0331c51f9fdc7df0b3459c70c80bde99750d14cbff0403
diff -r also reports differences

Only in /home/sagitter/1287846-python-lib389/srpm-unpacked/python-lib389-1.0.1-1.tar.bz2-extract: python-lib389-1.0.1-1
Only in /home/sagitter/1287846-python-lib389/upstream-unpacked/Source0: python-lib389-1.0.1-1.tar.bz2


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

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


Issues:
=======
- Sources used to build the package match the upstream source, as provided
  in the spec URL.
  Note: Upstream MD5sum check error, diff is in /home/sagitter/1287846
  -python-lib389/diff.txt
  See: http://fedoraproject.org/wiki/Packaging/SourceURL


===== 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". 69 files have unknown license. Detailed
     output of licensecheck in /home/sagitter/1287846-python-
     lib389/licensecheck.txt
[x]: Package contains no bundled libraries without FPC exception.
[!]: 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 10240 bytes in 1 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]: 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]: 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:
[-]: 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).
[ ]: Package functions as described.
[x]: Latest version is packaged.
[x]: 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.
[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)
[x]: Rpmlint is run on all installed packages.
     Note: No rpmlint messages.


Rpmlint
-------
Checking: python-lib389-1.0.1-1.fc24.noarch.rpm
          python-lib389-1.0.1-1.fc24.src.rpm
python-lib389.src: W: file-size-mismatch python-lib389-1.0.1-1.tar.bz2 = 103591, http://port389.org/binaries/python-lib389-1.0.1-1.tar.bz2 = 9568
2 packages and 0 specfiles checked; 0 errors, 1 warnings.




Rpmlint (installed packages)
----------------------------
1 packages and 0 specfiles checked; 0 errors, 0 warnings.



Diff spec file in url and in SRPM
---------------------------------
--- /home/sagitter/1287846-python-lib389/srpm/python-lib389.spec	2015-12-07 22:18:11.269105286 +0100
+++ /home/sagitter/1287846-python-lib389/srpm-unpacked/python-lib389.spec	2015-12-07 17:37:08.000000000 +0100
@@ -1,3 +1,7 @@
-Summary: A library for accessing, testing, and configuring the 389 Directory Server
+%global sum A library for accessing, testing, and configuring the 389 Directory Server
+%global desc This module contains tools and libraries for accessing, testing, \
+             and configuring the 389 Directory Server.
+
+Summary: %{sum}
 Name: python-lib389
 Version: 1.0.1
@@ -9,15 +13,20 @@
 BuildArch: noarch
 Url: http://port389.org/docs/389ds/FAQ/upstream-test-framework.html
-BuildRequires: python2-devel, python-ldap, krb5-devel, python-setuptools
+BuildRequires: python2-devel, python-ldap, krb5-devel
 Requires: pytest
 
 %description
-This module contains tools and libraries for accessing, testing, 
-and configuring the 389 Directory Server.
+%{desc}
 
 # Currently python-ldap is not python3 compatible, so python-lib389 only works 
 # with python 2.7
+
+%package -n python2-lib389
+Summary: %{sum}
 %{?python_provide:%python_provide python2-lib389}
 
+%description -n python2-lib389
+%{desc}
+
 %prep
 %setup -q -n %{name}-%{tarver}
@@ -41,7 +50,4 @@
 
 %changelog
-* Mon Dec 7 2015 Mark Reynolds <mreynolds> - 1.0.1-1
-- Removed downloaded dependencies, and added python_provide marco
- 
 * Fri Dec 4 2015 Mark Reynolds <mreynolds> - 1.0.1-1
 - Renamed package to python-lib389, and simplified the spec file
@@ -50,2 +56,5 @@
 - Bugzilla 1287846 - Submit lib389 python module to access the 389 Directory Server
 
+
+
+


Requires
--------
python-lib389 (rpmlib, GLIBC filtered):
    /usr/bin/env
    /usr/bin/python
    pytest
    python(abi)



Provides
--------
python-lib389:
    python-lib389



Source checksums
----------------
http://port389.org/binaries/python-lib389-1.0.1-1.tar.bz2 :
  CHECKSUM(SHA256) this package     : f7fda4d02fc50d91389c233c72df17f2214a98082a93d9754cdac9124be0edf6
  CHECKSUM(SHA256) upstream package : a9e65e0c788e7b2c8f0331c51f9fdc7df0b3459c70c80bde99750d14cbff0403
diff -r also reports differences


Generated by fedora-review 0.6.0 (3c5c9d7) last change: 2015-05-20
Command line :/usr/bin/fedora-review -m fedora-rawhide-x86_64 -b 1287846
Buildroot used: fedora-rawhide-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

I was able to fix the different source file size issue.  The spec file url needed "www." in front of port389.org.

The spec file and source tar balls are now in sync, and there are no errors or warnings from rpmlint on the rpm and srpm.  Mock build output looks correct and succeeds.

I'm not sure what the issue is with the changelog entries.  Please elaborate if there is still an issue.

Everything is uploaded now:

Spec URL: http://www.port389.org/binaries/python-lib389.spec
SRPM URL: http://www.port389.org/binaries/python-lib389-1.0.1-1.fc22.src.rpm

Thanks,
Mark

>%changelog
>* Mon Dec 7 2015 Mark Reynolds <mreynolds> - 1.0.1-1
>- Removed downloaded dependencies, and added python_provide macro
>- Fixed Source0 URL in spec file
> 
>* Fri Dec 4 2015 Mark Reynolds <mreynolds> - 1.0.1-1
>- Renamed package to python-lib389, and simplified the spec file
>
>* Tue Dec 1 2015 Mark Reynolds <mreynolds> - 1.0.1-1
>- Bugzilla 1287846 - Submit lib389 python module to access the 389 DS

Release number should be incremented but, in this case, multiple changelog entries is acceptable since package has not be built yet.

Package review is completed for me; you need a sponsor yet.
http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

I'm not sure why needsponsor was blocked; mreynolds is in currently in the packager group.

Antonio, why have you not approved the package (or assigned it to yourself or changed the fedora-review flag)?

If you mean to advertise your change to the review process, why not simply mention that change or link the initial thread on devel@ list?
 -> https://lists.fedoraproject.org/pipermail/devel/2015-November/217026.html

(In reply to Jason Tibbitts from comment #33)
> I'm not sure why needsponsor was blocked; mreynolds is in currently in the
> packager group.

Maybe FE-NEEDSPONSOR was a mistake of mreynolds but i did not checked.

@mreynolds
Do you need a sponsor or not?

> 
> Antonio, why have you not approved the package (or assigned it to yourself
> or changed the fedora-review flag)?

Because FE-NEEDSPONSOR block.

(In reply to Antonio Trande from comment #35)
> (In reply to Jason Tibbitts from comment #33)
> > I'm not sure why needsponsor was blocked; mreynolds is in currently in the
> > packager group.
> 
> Maybe FE-NEEDSPONSOR was a mistake of mreynolds but i did not checked.
> 
> @mreynolds
> Do you need a sponsor or not?
> 
> > 
> > Antonio, why have you not approved the package (or assigned it to yourself
> > or changed the fedora-review flag)?
> 
> Because FE-NEEDSPONSOR block.

I read just now that sponsoring and reviewing of first package are now distinct procedures: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Get_Sponsored

Package approved.

(In reply to Antonio Trande from comment #36)
> (In reply to Antonio Trande from comment #35)
> > (In reply to Jason Tibbitts from comment #33)
> > > I'm not sure why needsponsor was blocked; mreynolds is in currently in the
> > > packager group.
> > 
> > Maybe FE-NEEDSPONSOR was a mistake of mreynolds but i did not checked.

I was just following:

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_Your_Review_Request

> > 
> > @mreynolds
> > Do you need a sponsor or not?

Apparently not since I am in the packager group.  

https://fedorahosted.org/packager-sponsors/ticket/243

> > 
> > > 
> > > Antonio, why have you not approved the package (or assigned it to yourself
> > > or changed the fedora-review flag)?
> > 
> > Because FE-NEEDSPONSOR block.
> 
> I read just now that sponsoring and reviewing of first package are now
> distinct procedures:
> https://fedoraproject.org/wiki/
> Join_the_package_collection_maintainers#Get_Sponsored
> 
> Package approved.

Thanks Antonio!  I appreciated your help and patience on this!

Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/python-lib389