Bug 1256492 - Review Request: python-libnuma - Python bindings for the numactl library
Summary: Review Request: python-libnuma - Python bindings for the numactl library
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jiri Kastner
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: FE-NEEDSPONSOR 1083720
TreeView+ depends on / blocked
Reported: 2015-08-24 18:15 UTC by Guy Streeter
Modified: 2022-05-10 04:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2022-05-10 04:12:08 UTC
Type: ---
ppisar: fedora-review?

Attachments (Terms of Use)

Description Guy Streeter 2015-08-24 18:15:35 UTC
Spec URL: https://git.fedorahosted.org/cgit/python-libnuma.git/tree/rpm/SPECS/python3-libnuma.spec
SRPM URL: https://copr-be.cloud.fedoraproject.org/results/streeter/python-hwloc/fedora-22-x86_64/python3-libnuma-2.1.4-2.0.fc21/python3-libnuma-2.1.4-2.0.fc22.src.rpm
Description: Python bindings for the numactl library.
Required by the python-hwloc package (proposed in bug 1083720)
Fedora Account System Username: streeter

This and python-hwloc are my first 2 Fedora packages. I still do not have a sponsor.

I wrote and I maintain this package at

Build available at

Comment 1 Jiri Kastner 2015-08-26 07:42:40 UTC
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).

Comment 2 Guy Streeter 2015-08-26 14:26:05 UTC
 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,

Comment 3 Jiri Kastner 2015-08-26 15:41:19 UTC
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

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

Comment 4 Guy Streeter 2015-08-26 16:14:03 UTC
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.

Comment 5 Jiri Kastner 2015-08-26 21:15:53 UTC
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.

Comment 6 Guy Streeter 2015-08-26 22:05:35 UTC
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."


Comment 7 Jiri Kastner 2015-08-27 12:34:55 UTC
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.

Comment 8 Guy Streeter 2015-08-27 16:07:25 UTC
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.

Comment 9 Jiri Kastner 2015-08-27 17:05:34 UTC
+1 :)

Comment 10 Guy Streeter 2015-08-27 18:11:29 UTC
How does this look?

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

$ rpm -qlp RPMS/x86_64/python2-libnuma-2.2-2.0.fc21.x86_64.rpm 

$ rpm -qlp RPMS/x86_64/python3-libnuma-2.2-2.0.fc21.x86_64.rpm 

I followed the example in

koji scratch build

Comment 11 Jiri Kastner 2015-08-27 21:44:33 UTC
[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)

Comment 12 Guy Streeter 2015-08-27 21:59:34 UTC
I forgot to push a tag for it. There is am upstream source file now.

Comment 13 Jiri Kastner 2015-09-02 11:42:16 UTC
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

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

- 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

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

[ ]: 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.

[ ]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
[ ]: 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
[ ]: 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
[ ]: 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
[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
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

[ ]: Python eggs must not download any dependencies during the build
[ ]: 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 =====

[ ]: Package has no %clean section with rm -rf %{buildroot} (or
     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
[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
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

[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.

Checking: python2-libnuma-2.2-2.0.fc24.x86_64.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.

python2-libnuma (rpmlib, GLIBC filtered):

python3-libnuma (rpmlib, GLIBC filtered):



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

Comment 14 Guy Streeter 2015-09-15 19:32:24 UTC
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:

Available in copr:

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


Comment 15 Jiri Kastner 2015-09-16 08:25:09 UTC
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?


# 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.

Comment 16 Guy Streeter 2015-09-16 14:40:05 UTC
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.

Comment 17 Guy Streeter 2015-09-16 15:53:10 UTC
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.

Comment 18 Guy Streeter 2015-09-16 16:09:55 UTC
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.

Comment 21 Guy Streeter 2017-12-21 22:35:49 UTC
The git repo for python-libnuma is now at

and my email is guy.streeter

Comment 22 Package Review 2021-04-29 00:45:14 UTC
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.

Comment 23 Jiri Kastner 2021-05-05 11:38:29 UTC
@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

Comment 24 Guy Streeter 2021-05-05 15:14:22 UTC
I have retired. Nobody ever used this but me, and I don't any more.

Comment 25 Package Review 2022-05-06 00:45:20 UTC
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.

Comment 26 Guy Streeter 2022-05-06 13:34:13 UTC
I can't see a way for me to close this issue. I opened it, and I don't care about it any more.

Comment 27 Jiri Kastner 2022-05-10 04:12:08 UTC

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