Fedora Account System
Red Hat Associate
Red Hat Customer
Spec URL: https://jussilehtola.fedorapeople.org/python-geometric.spec SRPM URL: https://jussilehtola.fedorapeople.org/python-geometric-1.1.1-1.fc44.src.rpm Fedora Account System Username: jussilehtola Description: GeomeTRIC is a geometry optimization code for molecular structures. The code works by calling external software for the energy and gradient through wrapper functions.
This might interest @fedora
Copr build: https://copr.fedorainfracloud.org/coprs/build/10846187 (failed) Build log: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2513914-python-geometric/fedora-rawhide-x86_64/10846187-python-geometric/builder-live.log.gz Please make sure the package builds successfully at least for Fedora Rawhide. - If the build failed for unrelated reasons (e.g. temporary network unavailability), please ignore it. - If the build failed because of missing BuildRequires, please make sure they are listed in the "Depends On" field --- 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) Please change: BuildRequires: python3-devel BuildRequires: python3dist(networkx) BuildRequires: python3dist(numpy) >= 1.11 BuildRequires: python3dist(scipy) BuildRequires: python3dist(setuptools) BuildRequires: python3dist(si to BuildRequires: python3-devel BuildRequires: python3dist(pytest) Other requirements will be automatically generated. b) Please remove: Requires: python3dist(networkx) Requires: python3dist(numpy) >= 1.11 Requires: python3dist(scipy) Requires: python3dist(setuptools) Requires: python3dist(six) these will be automatically generated c) Please change: %pyproject_save_files geometric to %pyproject_save_files -L geometric so get an error if license is included automatically d) Consider packaging docs and examples as a separate subpackage
Apart from those: - the egginfo rm is a no-op, please droo - using `%autosetup` is preferred these days - why not use `%py3_shebang_fix` or at least open an upstream issue to remove them? - consider dropping the versioneer. It is weirdly licensed for us. At least raise an issue for them to migrate to something like setuptools-scm
The packaging guidelines https://docs.fedoraproject.org/en-US/packaging-guidelines/ still state > As an alternative to the usual %setup macro, the %autosetup can be used. I've made all other fixes. Spec URL: https://jussilehtola.fedorapeople.org/python-geometric.spec SRPM URL: https://jussilehtola.fedorapeople.org/python-geometric-1.1.1-2.fc44.src.rpm
Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed ===== MUST items ===== 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", "BSD 3-Clause License", "*No copyright* Public domain". 867 files have unknown license. Detailed output of licensecheck in /home/fedora-packaging/reviews/python-geomtric/2513914- python-geometric/licensecheck.txt [x]: Package must own all directories that it creates. Note: Directories without known owners: /usr/lib/python3.15/site- packages, /usr/lib/python3.15 [x]: Package contains no bundled libraries or specifies bundled libraries with Provides: bundled(<libname>) if unbundling is not possible. [x]: 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 [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. [ ]: 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]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 3613 bytes in 1 files. [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]: 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: [!]: Uses parallel make %{?_smp_mflags} macro. [x]: 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. [ ]: 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. [x]: 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: [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: python3-geometric-1.1.1-2.fc45.noarch.rpm python-geometric-1.1.1-2.fc45.src.rpm ============================ rpmlint session starts ============================ rpmlint: 2.8.0 configuration: /usr/lib/python3.14/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/tmptpix21ft')] checks: 32, packages: 2 python3-geometric.noarch: E: non-executable-script /usr/lib/python3.15/site-packages/geometric/tests/test_customengine.py 644 /usr/bin/python3 -sP python3-geometric.noarch: W: no-manual-page-for-binary geometric-neb python3-geometric.noarch: W: no-manual-page-for-binary geometric-optimize python3-geometric.noarch: W: no-manual-page-for-binary run-ase python-geometric.src: E: description-line-too-long GeomeTRIC is a geometry optimization code for molecular structures. The code works by calling external software for the energy and gradient through wrapper functions. python3-geometric.noarch: E: description-line-too-long GeomeTRIC is a geometry optimization code for molecular structures. The code works by calling external software for the energy and gradient through wrapper functions. 2 packages and 0 specfiles checked; 3 errors, 3 warnings, 8 filtered, 3 badness; has taken 2.7 s Rpmlint (installed packages) ---------------------------- ============================ rpmlint session starts ============================ rpmlint: 2.9.0 configuration: /usr/lib/python3.15/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: 1 python3-geometric.noarch: E: non-executable-script /usr/lib/python3.15/site-packages/geometric/tests/test_customengine.py 644 /usr/bin/python3 -sP python3-geometric.noarch: W: no-manual-page-for-binary geometric-neb python3-geometric.noarch: W: no-manual-page-for-binary geometric-optimize python3-geometric.noarch: W: no-manual-page-for-binary run-ase python3-geometric.noarch: E: description-line-too-long GeomeTRIC is a geometry optimization code for molecular structures. The code works by calling external software for the energy and gradient through wrapper functions. 1 packages and 0 specfiles checked; 2 errors, 3 warnings, 4 filtered, 2 badness; has taken 0.2 s Source checksums ---------------- https://github.com/leeping/geomeTRIC/archive/1.1.1/python-geometric-1.1.1.tar.gz : CHECKSUM(SHA256) this package : 3c9c48b39dbd66f6ee71edb63ae8f6bc53b57a3c487ad78bfcd06ab210052612 CHECKSUM(SHA256) upstream package : 3c9c48b39dbd66f6ee71edb63ae8f6bc53b57a3c487ad78bfcd06ab210052612 Requires -------- python3-geometric (rpmlib, GLIBC filtered): /usr/bin/python3 python(abi) python3.15dist(networkx) python3.15dist(numpy) python3.15dist(scipy) python3.15dist(six) Provides -------- python3-geometric: python-geometric python3-geometric python3.15-geometric python3.15dist(geometric) python3dist(geometric) Generated by fedora-review 0.11.0 (05c5b26) last change: 2025-11-29 Command line :/usr/bin/fedora-review -b 2513914 Buildroot used: fedora-rawhide-x86_64 Active plugins: Shell-api, Generic, Python Disabled plugins: Haskell, Perl, Ocaml, R, C/C++, fonts, PHP, Java, SugarActivity Disabled flags: EXARCH, EPEL6, EPEL7, DISTTAG, BATCH Comments: a) Mostly seems ok except for the CC0 code, you can also check if upstream would consider having that under MIT-0 or 0BSD. License-Ref-Public-Domain is also acceptable for code. b) Please put the description on two lines. c) Any reason the patch is not upstreamed? d) There are multiple build warnings of the form: ******************************************************************************** ############################ # Package would be ignored # ############################ Python recognizes 'geometric.data.ethane_qmmm_terachem_openmm' as an importable package[^1], but it is absent from setuptools' `packages` configuration. This leads to an ambiguous overall configuration. If you want to distribute this package, please make sure that 'geometric.data.ethane_qmmm_terachem_openmm' is explicitly added to the `packages` configuration field. Alternatively, you can also rely on setuptools' discovery methods (for example by using `find_namespace_packages(...)`/`find_namespace:` instead of `find_packages(...)`/`find:`). You can read more about "package discovery" on setuptools documentation page: - https://setuptools.pypa.io/en/latest/userguide/package_discovery.html If you don't want 'geometric.data.ethane_qmmm_terachem_openmm' to be distributed and are already explicitly excluding 'geometric.data.ethane_qmmm_terachem_openmm' via `find_namespace_packages(...)/find_namespace` or `find_packages(...)/find`, you can try to use `exclude_package_data`, or `include-package-data=False` in combination with a more fine grained `package-data` configuration. You can read more about "package data files" on setuptools documentation page: - https://setuptools.pypa.io/en/latest/userguide/datafiles.html [^1]: For Python, any directory (with suitable naming) can be imported, even if it does not contain any `.py` files. On the other hand, currently there is no concept of package data directory, all directories are treated like packages. ********************************************************************************
> The packaging guidelines https://docs.fedoraproject.org/en-US/packaging-guidelines/ still state > > As an alternative to the usual %setup macro, the %autosetup can be used. There is no realistic reason why not to use `%autopatch` (and `%autosetup` being just the combination of them). I have hit numerous times when a PR adds a patch and everyone forgets that it does not have an `%autopatch` and it is silently a no-op just to come back months later confused why it is still a problem. Be kind to the fellow contributors and use the `%autopatch`, or elaborate on why you do not like it.
(In reply to Cristian Le from comment #7) > > The packaging guidelines https://docs.fedoraproject.org/en-US/packaging-guidelines/ still state > > > As an alternative to the usual %setup macro, the %autosetup can be used. > > There is no realistic reason why not to use `%autopatch` (and `%autosetup` > being just the combination of them). I have hit numerous times when a PR > adds a patch and everyone forgets that it does not have an `%autopatch` and > it is silently a no-op just to come back months later confused why it is > still a problem. rpm issues a warning if there are patches that haven't been applied, this has never been an issue for me working 10+ years in Fedora. > Be kind to the fellow contributors and use the > `%autopatch`, or elaborate on why you do not like it. The reason why I dislike autopatch is that IIRC it is incompatible with fixing build failures. Updates to packages often lead to patches not applying; in the trivial case you just need to apply the patch manually as patch -p1 which is more robust about the development. Otherwise, I go in, adapt and put in the rejected changes, and regenerate the patch. This requires backups of the files with a known suffix. rpm documentation on autosetup and autopatch simply states -b (for creating patch backups) is accepted but currently ignored - this is not meaningful for a full-blown VCS anyway. If you need backups for gendiff use, use gendiff backend. So, in short, I don't remember having forgotten once to apply a patch in a production build, since rpm warns about it. In contrast, the suggested alternative basically has no documentation, and doesn't appear to implement basic functionality necessary for patch management.
Created attachment 2154380 [details] The .spec file difference from Copr build 10846187 to 10858656
Copr build: https://copr.fedorainfracloud.org/coprs/build/10858656 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2513914-python-geometric/fedora-rawhide-x86_64/10858656-python-geometric/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.