https://bugzilla.redhat.com/show_bug.cgi?id=1256492
Bug ID: 1256492 Summary: Review Request: python-libnuma - Python bindings for the numactl library Product: Fedora Version: rawhide Component: Package Review Severity: medium Priority: medium Assignee: nobody@fedoraproject.org Reporter: streeter@redhat.com QA Contact: extras-qa@fedoraproject.org CC: package-review@lists.fedoraproject.org
Spec URL: https://git.fedorahosted.org/cgit/python-libnuma.git/tree/rpm/SPECS/python3-... SRPM URL: https://copr-be.cloud.fedoraproject.org/results/streeter/python-hwloc/fedora... 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 https://git.fedorahosted.org/cgit/python-libnuma.git/
Build available at https://copr.fedoraproject.org/coprs/streeter/python-hwloc/builds/
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
Guy Streeter streeter@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |177841 (FE-NEEDSPONSOR)
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=177841 [Bug 177841] Tracker: Review requests from new Fedora packagers who need a sponsor
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
Antonio Trande anto.trande@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1083720
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1083720 [Bug 1083720] Review Request: python-hwloc - Python bindings for hwloc
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
Jiri Kastner jkastner@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jkastner@redhat.com Assignee|nobody@fedoraproject.org |jkastner@redhat.com
--- Comment #1 from Jiri Kastner jkastner@redhat.com --- 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).
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #2 from Guy Streeter streeter@redhat.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #3 from Jiri Kastner jkastner@redhat.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #4 from Guy Streeter streeter@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #5 from Jiri Kastner jkastner@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #6 from Guy Streeter streeter@redhat.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #7 from Jiri Kastner jkastner@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #8 from Guy Streeter streeter@redhat.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #9 from Jiri Kastner jkastner@redhat.com --- +1 :)
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #10 from Guy Streeter streeter@redhat.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #11 from Jiri Kastner jkastner@redhat.com --- [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... WARNING: Cannot download url: https://git.fedorahosted.org/cgit/python-libnuma.git/snapshot/python-libnuma... 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)
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #12 from Guy Streeter streeter@redhat.com --- I forgot to push a tag for it. There is am upstream source file now. --Guy
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #13 from Jiri Kastner jkastner@redhat.com ---
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... : 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
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #14 from Guy Streeter streeter@redhat.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #15 from Jiri Kastner jkastner@redhat.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #16 from Guy Streeter streeter@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #17 from Guy Streeter streeter@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #18 from Guy Streeter streeter@redhat.com --- numactl is not being built for arm:
* Sat Jun 18 2011 Peter Robinson pbrobinson@gmail.com - 2.0.7-2 - Exclude ARM platforms
I've copied the ExcludeArch line from the numactl specfile to mine.
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
--- Comment #19 from Guy Streeter streeter@redhat.com --- Above changes checked in.
http://koji.fedoraproject.org/koji/taskinfo?taskID=11111418 https://copr.fedoraproject.org/coprs/streeter/python-hwloc/
https://bugzilla.redhat.com/show_bug.cgi?id=1256492
Guy Streeter guy.streeter@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |guy.streeter@gmail.com
--- Comment #21 from Guy Streeter guy.streeter@gmail.com --- The git repo for python-libnuma is now at https://gitlab.com/guystreeter/python-libnuma.git
and my email is guy.streeter@gmail.com
package-review@lists.fedoraproject.org