Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Declarative build system support (#1087)
Found out about this new feature. How does one go about constructing such `BuildSystem`, do they just define a `%buildsystem__conf` macros? I am considering the case of [MPI packaging](https://pagure.io/packaging-committee/issue/1345) and it would be a neat approach to `for` looping all mpi variants. One thing that would be needed is to expand `BuildOption(section)` for specific variant, e.g.: `BuildOption(conf-serial)`. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1087#issuecomment-2018377515 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] FeatureRequest: rpm-spec: Specify minimum hardware requirements (Discussion #2909)
Opening a discussion related to [this copr issue](https://github.com/fedora-copr/copr/issues/3141#issuecomment-1943789962). **Background:** I've had a build on me take 5h with multiple timeouts when run with 2 CPU cores due to MPI + OpenMP oversubscription. While typically it only costs 1h on 4 cores. **Suggestions:** Provide a global macro where we can define the total number of CPU cores/memory etc. that a particular `.spec` file requires. This could be defined only once and be independent of `%if` statements to keep the parsing simple. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2909 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Spec file versioning macros (Issue #2443)
But when we use the formatting macro, we have the original git tag info, so we
can reuse it later. For the reverse, if we can extract the macro info, e.g.
from `%{version}` we could have `%{version_base}` and `%{version_prerel}` and
we can construct the git tag accordingly e.g.
`v%{version_base}%{?version_prerel:-%{version_prerel}`. This one I don't know
how useful it would be, but the first one I think it is very beneficial.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2443#issuecomment-1498712290
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Spec file versioning macros (Issue #2443)
This is a reference from fedora packaging committee
[issue](https://pagure.io/packaging-committee/issue/1264):
> I would like to propose a few helper macros for dealing with version control:
> - Format git tag -> rpm version: e.g. 1.2.3-rc1/1.2.3rc -> 1.2.3~rc1. This
> could be detected from [python's
> packaging.version](https://packaging.pypa.io/en/stable/version.html)
> - Format rpm version -> git tag/free format: e.g. 1.2.3~rc1 -> 1.2.3-rc1. An
> interface for this could be: %{version_format -base 1.2.3 -prerel rc1 -format
> v{base}-{prerel}} or if possible more automated %{version_format -version
> %{version} -format v{base}-{prerel}}
> - Detect version from git tag/.git_archival.txt similar to setuptools_scm.
> This would be incredibly useful for in-source packaging, but not in dist-gits
>
> These issues arose when trying to make packit be able to parse the version
> from git tags like v1.2.3-rc1. We can make a custom handling there, but it
> would be better to have a more standardized way to do this. The best case is
> to implement these upstream so that these can be used by OpenSuse as well.
>
> For reference here are a few workarounds that have to be maintained and are
> inconsistent with each other:
> [bluefish](https://src.fedoraproject.org/rpms/bluefish/blob/rawhide/f/bluefish.spec#_2),
>
> [cmake](https://src.fedoraproject.org/rpms/cmake/blob/rawhide/f/cmake.spec#_68)
Ideally it should be implemented here, but should it first be developed on
redhat rpm macros?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2443
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
