Fedora Account System
Red Hat Associate
Red Hat Customer
Spec URL: https://jussilehtola.fedorapeople.org/trexio.spec SRPM URL: https://jussilehtola.fedorapeople.org/trexio-2.6.1-1.fc44.src.rpm Fedora Account System Username: jussilehtola Description: TREXIO is an open-source file format and library developed for the storage and manipulation of data produced by quantum chemistry calculations. It was designed with the goal of providing a reliable and efficient method of storing and exchanging wave function parameters and matrix elements. The library consists of a front-end implemented in the C programming language and two different back-ends: a text back-end and a binary back-end utilizing the HDF5 library enabling fast read and write speeds. It is compatible with a variety of platforms and has interfaces for Fortran, Python, and OCaml.
[fedora-review-service-build]
Comments: a) Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=150595296 b) Please add sonames to the library listing c) Current repository head enables python package to be built with CMake. Will it take a long time to get a new release?
I made several contributions to upstream over the last week, since I organized a scientific conference with the main developer. I am pre-emptively already bumping the release to 3, as I found a mismatch between the Cmake and autotools packaging. The 3.0.0 release will be minted in a few weeks. https://jussilehtola.fedorapeople.org/trexio.spec https://jussilehtola.fedorapeople.org/trexio-3.0.0-0.1.8df4b44.fc44.src.rpm
Version convention does not follow versioning guidelines [1]. On top of that the project is not buildable from a git archive, a topic that was already raised with upstream, ans still unresolved now. [1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_snapshots
> On top of that the project is not buildable from a git archive, a topic that was already raised with upstream, ans still unresolved now. What do you mean? The spec does build. For koji builds, there is the issue that the build tries to pull from numpy upstream; this will be addressed upstream in the upcoming weeks.
Added missing snapshot date https://jussilehtola.fedorapeople.org/trexio.spec https://jussilehtola.fedorapeople.org/trexio-3.0.0-0.1.20260925.8df4b44.fc44.src.rpm [fedora-review-service-build]
> On top of that the project is not buildable from a git archive It's buildable, just requiring one more build dependency, emacs, to generate code from org files. But for released tarball emacs is not needed. I think we've discussed this in https://github.com/TREX-CoE/trexio/pull/273#discussion_r3755003059. So personally I wouldn't treat it as an issue.
There was an additional bug affecting i686 for which I have made a PR upstream. All koji arches are now green, see https://koji.fedoraproject.org/koji/taskinfo?taskID=150667833 https://jussilehtola.fedorapeople.org/trexio.spec https://jussilehtola.fedorapeople.org/trexio-3.0.0-0.2.20260925.8df4b44.fc44.src.rpm [fedora-review-service-build]
@susi.lehtola I know you find "ack" replies to be a waste of time, but others can view selectively replying only to parts of a comment rude, especially when it happens regularly. Anyway, please re-read the Versioning packaging guidelines, particularly in the usage of `~` and `^`, and the snapshot metadata in `Version`. Beware that one is for post and the other for pre releases. > It's buildable, just requiring one more build dependency, emacs, to generate code from org files. But for released tarball emacs is not needed. That does not seem to be intended, particularly since `TREXIO_DEVEL` is not passed and `TREXIO_MOD_FILE` generation is gated in there. I don't think I want to know why `build_trexio.sh` is being run in that logic, especially since upstream is deeming the `TREXIO_DEVEL` approach unsuited for a release anyway. As for the python packaging, building these from CMake only misses the `-dist-info` metadata that contain the dependencies as well as the package presence when doing something like `pip list`. Please see the `setup.py` and check if it can be run against a pre-installed trexio build-dir. I would rather recommend them to move it to `scikit-build-core` and have a proper build-system to detect trexio library. See spglib if you want a reference for how to design the cmake project to support that.
@lecris you didn't itemize the issue and I already took care of your non-itemized versioning issue. Comments that can be interpreted as RTFM are not very constructive either and can be construed rude. I also note that your comment still does not say anything about the issue. I would like to underline that the versioning is a placeholder for the review procedure; I have no intention of importing the package before the final v3.0.0 release is minted. As to the latter part of your message, it refers to discussion unrelated to this package; it's a discussion between yourself and SY Wang. As you can see, the package builds with emacs. By Fedora policy, packages should be built from original sources, which are the org-mode files. Relying on preprocessed source goes against the spirit of open source, which is that the original sources - the org-mode files - are modifiable. Any discussion on any issues in the trexio build system should not happen here, but instead be directed at the upstream trexio github where the main developers of the library can participate in the discussion.
> Relying on preprocessed source goes against the spirit of open source, which is that the original sources - the org-mode files - are modifiable. Do I have to point out the hypocrisy in that statement with your libxc:src/maple2c? I am aware of the need to reproduce the generated code in the build, and I flagged upstream about it. But that is not the point that I am making about `build_trexio.sh` here. The build of a specific commit is not supported by upstream, and the only way around it is through `TREXIO_DEVEL` which is not being used here. How on earth you managed to get it to build I don't know, and I don't want the responsibility to figure that out. > Comments that can be interpreted as RTFM are not very constructive either and can be construed rude. I also note that your comment still does not say anything about the issue. I would like to underline that the versioning is a placeholder for the review procedure; I have no intention of importing the package before the final v3.0.0 release is minted. So is this up for review or not? If it is, then follow the versioning guidelines. As for "being rude", do I have to point to the instances when your replies are basically just that as well? If you do not like that, well be more constructive in your replies as well. And to spell out the issue, the snapshot details should be in Version, not Release. And yes it does matter and there are ways it can break. The should is not just a decoration here. > Any discussion on any issues in the trexio build system should not happen here, but instead be directed at the upstream trexio github where the main developers of the library can participate in the discussion. Well are you going to be the main maintainer? In which case you also have a responsibility to open and forward these issues, acting as the future Fedora maintainer for this package. Again the python packaging issue, is not a decoration, it is an issue that needs to be resolved in order for this review. As it stands, `python3-trexio` is not in a packageable form.
Upstream has a weird attitude about only building from their release tarballs due to bad experiences (i) a long time ago (ii) without standard build infrastucture. If you look at the log, the build silently uses developer mode since it detects .devel. Since there are no nightly release builds, it's impossible to build the state-of-the-art software without doing this. The latest stable release has several bugs and defects that prevent its use in packages, e.g. the lack of a proper python build. As to the versioning guidelines, it appears those have changed over the years; when I started doing Fedora packaging almost 20 years ago the releases were marked in the release tag. Like I said, the package is not going to be imported until the 3.0.0 release is minted upstream, and according to Fedora policy, it is perfectly alright to reset the changelog and version history upon inclusion in Fedora. Thank you for pointing out the missing metadata and explaining why it matters; I will look into patching this upstream. PS. there's a world of difference between pregeneration that takes days (libxc) and pregeneration that takes fractions of a millisecond (trexio).