Spec URL: https://music.fedorapeople.org/python-pyscipopt.spec SRPM URL: https://music.fedorapeople.org/python-pyscipopt-5.5.0-1.fc42.src.rpm Description: This project provides an interface from Python to the SCIP Optimization Suite. Fedora Account System Username: music As Cython-based Python extensions go, this is a relatively straightforward one. This submission uses the provisional pyproject declarative buildsystem, which means that some of the spec-file sections you would normally expect to see are implicit. For details, see the section “Provisional: Declarative Buildsystem (RPM 4.20+)” at https://src.fedoraproject.org/rpms/pyproject-rpm-macros.
Copr build: https://copr.fedorainfracloud.org/coprs/build/9105405 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2369464-python-pyscipopt/fedora-rawhide-x86_64/09105405-python-pyscipopt/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Initial comments: a) It seems possible to build the documentation in docbook format which can be viewed using Yelp or KHelpCenter https://copr.fedorainfracloud.org/coprs/fed500/python-pyscipopt/builds/ b) libscip-devel is not available on i686
(In reply to Benson Muite from comment #2) > Initial comments: > a) It seems possible to build the documentation in docbook format which can > be > viewed using Yelp or KHelpCenter Sure, but why bring in the extra dependencies just to package documentation in a format that almost no other Python packages in Fedora use? Who will expect it, find it, or use it? Building HTML documentation is probably possible, but problematic due to bundled fonts, JS, CSS and so on; see bug 2006555. FESCo decisions https://pagure.io/fesco/issue/3177 and https://pagure.io/fesco/issue/3269 have made this more feasible, but still messy to try to do correctly. I briefly considered building PDF documentation, but this is something I’ve been trying to get away from: the TexLive dependency is very heavy, and I’ve had several packages where the PDF documentation breaks in what is otherwise a minor, compatible update, which puts me in a bind where I cannot update without dropping the documentation. In this *particular* package, building the documentation as PDF fails without giving a clear error. Overall, I’ve long been in favor of the *idea* of packaged offline documentation, but I’ve gradually been won over to the perspective that documentation generated by Sphinx or Doxygen tends to be more trouble than it is worth to package, and I have been actively working to reduce the number of packages I maintain with this kind of documentation, not increase it. > https://copr.fedorainfracloud.org/coprs/fed500/python-pyscipopt/builds/ > > b) libscip-devel is not available on i686 That’s a great observation. Thanks. I’ll add ExcludeArch to this package.
Updated with ExcludeArch: %{ix86} New Spec URL: https://music.fedorapeople.org/20250531/python-pyscipopt.spec New SRPM URL: https://music.fedorapeople.org/20250531/python-pyscipopt-5.5.0-1.fc42.src.rpm
(In reply to Ben Beasley from comment #3) > (In reply to Benson Muite from comment #2) > > Initial comments: > > a) It seems possible to build the documentation in docbook format which can > > be > > viewed using Yelp or KHelpCenter > > Sure, but why bring in the extra dependencies just to package documentation > in a format that almost no other Python packages in Fedora use? Who will > expect it, find it, or use it? > For Sphinx, it is possible to add macros to make this easier, as new macros are being added, it is a good time to consider this and make people aware it is available. > Building HTML documentation is probably possible, but problematic due to > bundled fonts, JS, CSS and so on; see bug 2006555. FESCo decisions > https://pagure.io/fesco/issue/3177 and https://pagure.io/fesco/issue/3269 > have made this more feasible, but still messy to try to do correctly. > Docbook does not introduce extra fonts, js or CSS and there is a viewer already packaged. There is some expertise in Fedora for docbook format: https://packages.fedoraproject.org/pkgs/publican/ > I briefly considered building PDF documentation, but this is something I’ve > been trying to get away from: the TexLive dependency is very heavy, and I’ve > had several packages where the PDF documentation breaks in what is otherwise > a minor, compatible update, which puts me in a bind where I cannot update > without dropping the documentation. In this *particular* package, building > the documentation as PDF fails without giving a clear error. > pdf bundles fonts, does not really adapt to screen size and is much larger than docbook. > Overall, I’ve long been in favor of the *idea* of packaged offline > documentation, but I’ve gradually been won over to the perspective that > documentation generated by Sphinx or Doxygen tends to be more trouble than > it is worth to package, and I have been actively working to reduce the > number of packages I maintain with this kind of documentation, not increase > it. > > > https://copr.fedorainfracloud.org/coprs/fed500/python-pyscipopt/builds/ > > > > b) libscip-devel is not available on i686 > > That’s a great observation. Thanks. I’ll add ExcludeArch to this package. Thanks.
(In reply to Benson Muite from comment #5) > > For Sphinx, it is possible to add macros to make this easier, as new > macros are being added, it is a good time to consider this and make > people aware it is available. > > […] > > Docbook does not introduce extra fonts, js or CSS and there is a viewer > already packaged. There is some expertise in Fedora for docbook format: > https://packages.fedoraproject.org/pkgs/publican/ Indeed, Docbook looks like it has potential for this kind of documentation, and I am interested in the idea of a better way to deal with Sphinx-generated documentation in general. I just don’t see a reason for this particular package to be in the vanguard of that. I’m not saying it’s a bad format. It does seem to avoid a lot of the pitfalls of some other formats, which is kind of exciting, although I haven’t reviewed the result in a viewer to see how well it actually turned out. I’m just not sure that introducing Sphinx-generated docbook files to a handful of individual packages does much good except as a proof of concept. It seems like, for the effort of building this kind of documentation to be worthwhile, we need at least a partial consensus that (1) “we collectively value packaging generated Python library API documentation,” (2) “Sphinx-generated docbook output is normally of good quality in practice,” and (3) “this is how we would like to present Python library API documentation by default,“ especially for a format that many people, even developers, aren’t used to dealing with. If that consensus existed, I could quickly add docbook documentation to *dozens* of packages, even only considering those for which I am primary maintainer, but I am not yet confident that adding and maintaining this format is a good use of time and other resources.
(In reply to Ben Beasley from comment #6) > (In reply to Benson Muite from comment #5) > > > > For Sphinx, it is possible to add macros to make this easier, as new > > macros are being added, it is a good time to consider this and make > > people aware it is available. > > > > […] > > > > Docbook does not introduce extra fonts, js or CSS and there is a viewer > > already packaged. There is some expertise in Fedora for docbook format: > > https://packages.fedoraproject.org/pkgs/publican/ > > Indeed, Docbook looks like it has potential for this kind of documentation, > and I am interested in the idea of a better way to deal with > Sphinx-generated documentation in general. I just don’t see a reason for > this particular package to be in the vanguard of that. > > I’m not saying it’s a bad format. It does seem to avoid a lot of the > pitfalls of some other formats, which is kind of exciting, although I > haven’t reviewed the result in a viewer to see how well it actually turned > out. I’m just not sure that introducing Sphinx-generated docbook files to a > handful of individual packages does much good except as a proof of concept. > > It seems like, for the effort of building this kind of documentation to be > worthwhile, we need at least a partial consensus that (1) “we collectively > value packaging generated Python library API documentation,” (2) > “Sphinx-generated docbook output is normally of good quality in practice,” > and (3) “this is how we would like to present Python library API > documentation by default,“ especially for a format that many people, even > developers, aren’t used to dealing with. If that consensus existed, I could > quickly add docbook documentation to *dozens* of packages, even only > considering those for which I am primary maintainer, but I am not yet > confident that adding and maintaining this format is a good use of time and > other resources. Rendering in yelp is good and consistent. The only issue for the current package is latex is not correctly converted, but this is an upstream problem. The format is stable, and there is already significant functional tooling. The only factor complicating building this documentation is that the sometimes needs to already be available, requiring either modifying PYTHON_PATH or using a bootstrap build. As docbook can be produced from texinfo files, not only sphinx, but other documentation generators such as doxygen can also be used. Last build at https://copr.fedorainfracloud.org/coprs/fed500/python-pyscipopt/builds/ includes images. It is not a blocking requirement to include it, but maybe worth viewing the documentation to give an opinion.
Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= - Package contains BR: python2-devel or python3-devel ===== MUST items ===== C/C++: [x]: 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: [x]: 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", "MIT License", "*No copyright* MIT License". 191 files have unknown license. Detailed output of licensecheck in /home/fedora-packaging/reviews/python- pyscipopt/2369464-python-pyscipopt/licensecheck.txt [x]: License file installed when any subpackage combination is installed. [x]: Package must own all directories that it creates. Note: Directories without known owners: /usr/lib64/python3.13/site- packages, /usr/lib64/python3.13 [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. [x]: 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]: 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 299685 bytes in 62 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]: The License field must be a valid SPDX expression. [x]: Package requires other packages for directories it uses. [x]: Package does not own files or directories owned by other packages. [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 must not depend on deprecated() packages. [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]: Packages MUST NOT have dependencies (either build-time or runtime) on packages named with the unversioned python- prefix unless no properly versioned package exists. Dependencies on Python packages instead MUST use names beginning with python2- or python3- as appropriate. [x]: Python packages must not contain %{pythonX_site(lib|arch)}/* in %files [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). [x]: Fully versioned dependency in subpackages if applicable. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in python3-pyscipopt , python-pyscipopt-examples [ ]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [x]: Patches link to upstream bugs/comments/lists or are otherwise justified. [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. [ ]: Package should compile and build into binary rpms on all supported architectures. [x]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [!]: 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: There are rpmlint messages (see attachment). [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. Rpmlint ------- Checking: python3-pyscipopt-5.5.0-1.fc43.x86_64.rpm python-pyscipopt-examples-5.5.0-1.fc43.noarch.rpm python-pyscipopt-5.5.0-1.fc43.src.rpm ============================ rpmlint session starts ============================ rpmlint: 2.6.1 configuration: /usr/lib/python3.13/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora-spdx-licenses.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml rpmlintrc: [PosixPath('/tmp/tmps2dc44k9')] checks: 32, packages: 3 python-pyscipopt.spec: W: patch-not-applied Patch0: %{url}/pull/1008.patch python-pyscipopt-examples.noarch: W: package-with-huge-docs 99% python-pyscipopt.spec: W: no-%install-section 3 packages and 0 specfiles checked; 0 errors, 3 warnings, 10 filtered, 0 badness; has taken 0.8 s Rpmlint (installed packages) ---------------------------- ============================ rpmlint session starts ============================ rpmlint: 2.7.0 configuration: /usr/lib/python3.13/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora-spdx-licenses.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml checks: 32, packages: 2 python-pyscipopt-examples.noarch: W: package-with-huge-docs 99% 2 packages and 0 specfiles checked; 0 errors, 1 warnings, 6 filtered, 0 badness; has taken 0.2 s Unversioned so-files -------------------- python3-pyscipopt: /usr/lib64/python3.13/site-packages/pyscipopt/scip.cpython-313-x86_64-linux-gnu.so Source checksums ---------------- https://github.com/scipopt/PySCIPOpt/archive/v5.5.0/PySCIPOpt-5.5.0.tar.gz : CHECKSUM(SHA256) this package : e0a7de92442e03fdb177afc5b66706d308bc729b21d39d64f5347d3e373b954d CHECKSUM(SHA256) upstream package : e0a7de92442e03fdb177afc5b66706d308bc729b21d39d64f5347d3e373b954d Requires -------- python3-pyscipopt (rpmlib, GLIBC filtered): libc.so.6()(64bit) libscip.so.9.2()(64bit) python(abi) python3.13dist(numpy) rtld(GNU_HASH) python-pyscipopt-examples (rpmlib, GLIBC filtered): Provides -------- python3-pyscipopt: python-pyscipopt python3-pyscipopt python3-pyscipopt(x86-64) python3.13-pyscipopt python3.13dist(pyscipopt) python3dist(pyscipopt) python-pyscipopt-examples: python-pyscipopt-examples Diff spec file in url and in SRPM --------------------------------- --- /home/fedora-packaging/reviews/python-pyscipopt/2369464-python-pyscipopt/srpm/python-pyscipopt.spec 2025-05-31 18:49:30.601275834 +0300 +++ /home/fedora-packaging/reviews/python-pyscipopt/2369464-python-pyscipopt/srpm-unpacked/python-pyscipopt.spec 2025-05-30 03:00:00.000000000 +0300 @@ -15,8 +15,4 @@ BuildOption(install): -l pyscipopt -# https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval -# Furthermore, dependency libscip is ExcludeArch: %%{ix86}. -ExcludeArch: %{ix86} - BuildRequires: gcc-c++ BuildRequires: libscip-devel Generated by fedora-review 0.10.0 (e79b66b) last change: 2023-07-24 Command line :/usr/bin/fedora-review -b 2369464 Buildroot used: fedora-rawhide-x86_64 Active plugins: Generic, Shell-api, Python Disabled plugins: SugarActivity, PHP, Perl, C/C++, fonts, Ocaml, Java, R, Haskell Disabled flags: EXARCH, EPEL6, EPEL7, DISTTAG, BATCH Comment: a) Tutorial has a different license: https://github.com/scipopt/PySCIPOpt/blob/master/examples/tutorial/logical.py#L9 https://github.com/scipopt/PySCIPOpt/blob/master/examples/tutorial/even.py#L4 b) Other than a, it seems ok.
> a) Tutorial has a different license: > https://github.com/scipopt/PySCIPOpt/blob/master/examples/tutorial/logical.py#L9 > https://github.com/scipopt/PySCIPOpt/blob/master/examples/tutorial/even.py#L4 Thanks for catching this! The brief phrase “Public Domain, WTFNMFPL Public Licence” is surprisingly messy. It seems like this is a conflation of the WTFNMFPL with a public-domain dedication, which isn’t necessarily quite right, rather than an attempt to dual-license the files. If it were truly a public-domain dedication, it would need to be validated and added to https://gitlab.com/fedora/legal/fedora-license-data/-/blob/main/public-domain-text.txt. Meanwhile, the WTFNMFPL, https://github.com/adversary-org/wtfnmf/blob/master/COPYING.WTFNMFPL, has not been evaluated for allowability in Fedora, and is not even in SPDX yet. It may be best for me to submit this new license for review and, at the same time, submit a version of those package with a modified source archive that has those files filtered out, so that this package is not blocked on license review.
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/663
I prepared an updated submission with the WTFNMFPL-licensed tutorial scripts filtered out of the source archive while that license awaits legal review. New Spec URL: https://music.fedorapeople.org/20250602/python-pyscipopt.spec New SRPM URL: https://music.fedorapeople.org/20250602/python-pyscipopt-5.5.0-1.fc42.src.rpm Assuming the license is approved in https://gitlab.com/fedora/legal/fedora-license-data/-/issues/663 and is eventually assigned the SPDX identifier WTFNMFPL, then at that time, I will go back to using the unfiltered source archive, and the license-related portions of the spec file will look like this: # The entire source is MIT, except examples/tutorial/even.py and # examples/tutorial/logical.py, which are WTFNMFPL, and which are # packaged only in the examples subpackage. License: MIT AND WTFNMFPL […] %package -n python3-pyscipopt Summary: %{summary} License: MIT
Created attachment 2092650 [details] The .spec file difference from Copr build 9105405 to 9110475
Copr build: https://copr.fedorainfracloud.org/coprs/build/9110475 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2369464-python-pyscipopt/fedora-rawhide-x86_64/09110475-python-pyscipopt/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Thanks. Approved. Review of https://bugzilla.redhat.com/show_bug.cgi?id=2372326 would be appreciated if time allows.
Thank you for the review! https://release-monitoring.org/project/54158/
The Pagure repository was created at https://src.fedoraproject.org/rpms/python-pyscipopt