instead of 2 specfiles, ther should be one and not in rpm/SPECS folder but in toplevel directory (good for tito for example and for rpmbuild too).

Jiri,
 Thank you for reviewing this package.

The source is used to build two separate packages, python-libnuma and python3-libnuma. That's the reason there are 2 specfiles.

I don't know what tito is. Is that something I need?
Why does rmpbuild need the specfiles in the top-level directory?

The package is designed to build and install from setup.py for platforms that don't use rpm. It seems like packaging-specific files should be in their own directory. tuna, python-linux-procfs, and python-schedutils all have this directory layout.

The top-level Makefile has a target to build rpms.

thanks again,
--Guy

tito - https://github.com/dgoodwin/tito

rpmbuild with -tX options works on tarball directly if spec file is in toplevel directory

you can have one specfile and put all to it. and use 
%global with_python3 1
%if 0%{?with_python3}
...
%{__python3} setup.py build
...
%endif

see https://fedoraproject.org/wiki/Python3.4GuidlinesDraft

The combined specfile would have to be edited and checked in to build each of the packages, one at a time. I don't see an advantage to that.

Keeping them separate will also allow fixes and updates to be made independently for the two packages.

hey man, do you want to get package reviewed? :)
one specfile means one review, less mess.
i'm not aware of any package maintained in way you want to go.
i would understand your attitude if resulting specfile would look like kernel specfile, but that is exception.
with two specfiles and two srpms in case of abandoning python2 in future of fedora means retiring packages.
i would also understand your attitude if you will have two separated repositories, but you you have code in one repo.

I promise I'm not trying to be difficult. If that's the correct way to set it up, I'll change it.

Perhaps there's something about the way packages are built in the distro I don't understand. I assumed a src.rpm was submitted to the the build system. Is that incorrect? Not being a maintainer, I haven't ever participated in that process.

I've looked for information about how you get from source code to built package in the repo, but I can't find it. If I knew that, I could make sure my source is prepared for it. Do you have a link to that?

I'd be really happy to see something that says "this is how your source tree should be laid out."

thanks,
--Guy

for example dnf:
upstream - https://github.com/rpm-software-management/dnf
and fedora git tree for package - http://pkgs.fedoraproject.org/cgit/dnf.git/tree/ for specfile and patches

tarball is in sideload

usig fedpkg try this:

"fedpkg clone -a dnf"

and clone from github dnf repo.
srpm or tar.gz you can get using tito build --tgz or tito build --srpm.

from that you can see, that from one upstream source is generated one spoecfile, one tarball and srpm.

I understand now. I thought you were saying I should make a specfile that would be edited to produce each package, one at a time.
I can create a specfile that builds both packages at the same time. I'll start work on that.
thanks,
--Guy

+1 :)

How does this look?

$ rpm -qlp SRPMS/python-libnuma-2.2-2.0.fc21.src.rpm
python-libnuma-2.2-2.0.tar.gz
python-libnuma.spec

$ rpm -qlp RPMS/x86_64/python2-libnuma-2.2-2.0.fc21.x86_64.rpm 
/usr/lib64/python2.7/site-packages/libnuma.so
/usr/lib64/python2.7/site-packages/python2_libnuma-2.0-py2.7.egg-info
/usr/share/doc/python2-libnuma
/usr/share/doc/python2-libnuma/COPYING
/usr/share/doc/python2-libnuma/LICENSE
/usr/share/locale/en_US/LC_MESSAGES/python2-libnuma.mo

$ rpm -qlp RPMS/x86_64/python3-libnuma-2.2-2.0.fc21.x86_64.rpm 
/usr/lib64/python3.4/site-packages/libnuma.cpython-34m.so
/usr/lib64/python3.4/site-packages/python3_libnuma-2.0-py3.4.egg-info
/usr/share/doc/python3-libnuma
/usr/share/doc/python3-libnuma/COPYING
/usr/share/doc/python3-libnuma/LICENSE
/usr/share/locale/en_US/LC_MESSAGES/python3-libnuma.mo

I followed the example in
https://fedoraproject.org/wiki/Packaging:Python#Common_SRPM_vs_split_SRPMs

koji scratch build
http://koji.fedoraproject.org/koji/taskinfo?taskID=10858080

[indy@localhost python-libnuma]$ rpmbuild -bs ~/rpmbuild/SPECS/python-libnuma.spec 
Wrote: /home/indy/rpmbuild/SRPMS/python-libnuma-2.2-2.0.fc22.src.rpm
[indy@localhost python-libnuma]$ cp ~/rpmbuild/SRPMS/python-libnuma-2.2-2.0.fc22.src.rpm .
[indy@localhost python-libnuma]$ fedora-review -n python-libnuma
INFO: Processing local files: python-libnuma
INFO: Getting .spec and .srpm Urls from : Local files in /home/indy/packaging/review/python-libnuma
INFO:   --> SRPM url: file:///home/indy/packaging/review/python-libnuma/python-libnuma-2.2-2.0.fc22.src.rpm
INFO:   --> Spec url: file:///home/indy/packaging/review/python-libnuma/python-libnuma.spec
INFO: Using review directory: /home/indy/packaging/review/python-libnuma/review-python-libnuma
INFO: Downloading (Source0): https://git.fedorahosted.org/cgit/python-libnuma.git/snapshot/python-libnuma-2.2-2.0.tar.gz
WARNING: Cannot download url: https://git.fedorahosted.org/cgit/python-libnuma.git/snapshot/python-libnuma-2.2-2.0.tar.gz
INFO: Using local file python-libnuma-2.2-2.0.tar.gz as Source0
INFO: Running checks and generating report
INFO: Results and/or logs in: /home/indy/packaging/review/python-libnuma/review-python-libnuma/results
INFO: WARNING: Probably non-rawhide buildroot used. Rawhide should be used for most package reviews
INFO: Build completed
INFO: Installing built package(s)
INFO: Active plugins: Python, Generic, Shell-api
ERROR: 'Source0: upstream source not found' (logs in /home/indy/.cache/fedora-review.log)

I forgot to push a tag for it. There is am upstream source file now.
--Guy

This is a review *template*. Besides handling the [ ]-marked tests you are
also supposed to fix the template before pasting into bugzilla:
- Add issues you find to the list of issues on top. If there isn't such
  a list, create one.
- Add your own remarks to the template checks.
- Add new lines marked [!] or [?] when you discover new things not
  listed by fedora-review.
- Change or remove any text in the template which is plain wrong. In this
  case you could also file a bug against fedora-review
- Remove the "[ ] Manual check required", you will not have any such lines
  in what you paste.
- Remove attachments which you deem not really useful (the rpmlint
  ones are mandatory, though)
- Remove this text



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


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

C/C++:
[ ]: Development (unversioned) .so files in -devel subpackage, if present.
     Note: Unversioned so-files in private %_libdir subdirectory (see
     attachment). Verify they are not in ld path.

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". 3 files have unknown license. Detailed
     output of licensecheck in /home/indy/packaging/review/python-libnuma
     /review-python-libnuma/licensecheck.txt
[ ]: License file installed when any subpackage combination is installed.
[ ]: %build honors applicable compiler flags or justifies otherwise.
[ ]: Package contains no bundled libraries without FPC exception.
[ ]: Changelog in prescribed format.
[ ]: 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
[ ]: Package uses nothing in %doc for runtime.
[ ]: The spec file handles locales properly.
[ ]: 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.
[ ]: Useful -debuginfo package or justification otherwise.
[ ]: 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 61440 bytes in 4 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:
[ ]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
     Note: %clean present but not required
[ ]: 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
     python2-libnuma , python3-libnuma
[ ]: 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.
[ ]: %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]: Buildroot is not present
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: SourceX is a working URL.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[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]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: python2-libnuma-2.2-2.0.fc24.x86_64.rpm
          python3-libnuma-2.2-2.0.fc24.x86_64.rpm
          python-libnuma-2.2-2.0.fc24.src.rpm
python2-libnuma.x86_64: W: spelling-error %description -l en_US numactl -> numeracy
python2-libnuma.x86_64: W: unstripped-binary-or-object /usr/lib64/python2.7/site-packages/libnuma.so
python3-libnuma.x86_64: W: spelling-error %description -l en_US numactl -> numeracy
python3-libnuma.x86_64: W: unstripped-binary-or-object /usr/lib64/python3.4/site-packages/libnuma.cpython-34m.so
3 packages and 0 specfiles checked; 0 errors, 4 warnings.




Rpmlint (installed packages)
----------------------------
python2-libnuma.x86_64: W: unstripped-binary-or-object /usr/lib64/python2.7/site-packages/libnuma.so
python3-libnuma.x86_64: W: unstripped-binary-or-object /usr/lib64/python3.4/site-packages/libnuma.cpython-34m.so
2 packages and 0 specfiles checked; 0 errors, 2 warnings.



Requires
--------
python2-libnuma (rpmlib, GLIBC filtered):
    libc.so.6()(64bit)
    libnuma.so.1()(64bit)
    libnuma.so.1(libnuma_1.1)(64bit)
    libnuma.so.1(libnuma_1.2)(64bit)
    libpthread.so.0()(64bit)
    libpython2.7.so.1.0()(64bit)
    python(abi)
    rtld(GNU_HASH)

python3-libnuma (rpmlib, GLIBC filtered):
    libc.so.6()(64bit)
    libnuma.so.1()(64bit)
    libnuma.so.1(libnuma_1.1)(64bit)
    libnuma.so.1(libnuma_1.2)(64bit)
    libpthread.so.0()(64bit)
    libpython3.4m.so.1.0()(64bit)
    python(abi)
    rtld(GNU_HASH)



Provides
--------
python2-libnuma:
    python-libnuma
    python2-libnuma
    python2-libnuma(x86-64)

python3-libnuma:
    libnuma.cpython-34m.so()(64bit)
    python3-libnuma
    python3-libnuma(x86-64)



Unversioned so-files
--------------------
python2-libnuma: /usr/lib64/python2.7/site-packages/libnuma.so
python3-libnuma: /usr/lib64/python3.4/site-packages/libnuma.cpython-34m.so

Source checksums
----------------
https://git.fedorahosted.org/cgit/python-libnuma.git/snapshot/python-libnuma-2.2-2.0.tar.gz :
  CHECKSUM(SHA256) this package     : a5806902a1874546521acc99956e97cb76628e7910211227554e56894da966a3
  CHECKSUM(SHA256) upstream package : 8a1fd56aa967cb5fb3767109ad1f575faa8f259d6fac3f65ad911f54426d58cb
However, diff -r shows no differences


Generated by fedora-review 0.6.0 (3c5c9d7) last change: 2015-05-20
Command line :/usr/bin/fedora-review -v -n python-libnuma -m fedora-rawhide-x86_64
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've committed version 2.2.3-2.0:
 removed %clean
 added %check
 stripped the binary
 added license text to source files.

Built in koji:
http://koji.fedoraproject.org/koji/taskinfo?taskID=11098362

Available in copr:
https://copr.fedoraproject.org/coprs/streeter/python-hwloc/

What else should I do? Are there things in the fedora-review that I need to address?

thanks,
--Guy

why "ExclusiveArch:  x86_64" is not buildable for arm and i386 which are also primary architectures?
why not use this like in packaging guidelines for python?

%build
%py2_build
%py3_build

%install
# Must do the python2 install first because the scripts in /usr/bin are
# overwritten with every setup.py install, and in general we want the
# python3 version to be the default.
%py2_install
%py3_install

As far as I know, only x86_64 has NUMA architecture. When I started this, libnuma was only available on that architecture.
I see that it is available for the rest now, so I can remove that arch restriction.

I'll test the py?_build macros to see if they will work. I had problems using them before.

The py?_install macros should be OK. They seem to do the same thing my command does. I'll change that.

The py3_build/install macros are not available in Fedora 21. They were added to F22.
I'll change the python2 commands to use the macros, but leave the python3 commands as they are until F21 End Of Life.

numactl is not being built for arm:

* Sat Jun 18 2011 Peter Robinson <pbrobinson> - 2.0.7-2
- Exclude ARM platforms

I've copied the ExcludeArch line from the numactl specfile to mine.

Above changes checked in.

http://koji.fedoraproject.org/koji/taskinfo?taskID=11111418
https://copr.fedoraproject.org/coprs/streeter/python-hwloc/

The git repo for python-libnuma is now at
https://gitlab.com/guystreeter/python-libnuma.git

and my email is guy.streeter

This is an automatic check from review-stats script.

This review request ticket hasn't been updated for some time, but it seems
that the review is still being working out by you. If this is right, please
respond to this comment clearing the NEEDINFO flag and try to reach out the
submitter to proceed with the review.

If you're not interested in reviewing this ticket anymore, please clear the
fedora-review flag and reset the assignee, so that a new reviewer can take
this ticket.

Without any reply, this request will shortly be resetted.

@guy.streeter can you please update with current python guidelines? (python2 removal and so on) if this request is still actual for you?
also python-hwloc

I have retired. Nobody ever used this but me, and I don't any more.