Ticket 9293 - pmix version incorrectly calculated in RPM spec
Summary: pmix version incorrectly calculated in RPM spec
Status: RESOLVED DUPLICATE of ticket 11973
Alias: None
Product: Slurm
Classification: Unclassified
Component: PMIx (show other tickets)
Version: 20.02.3
Hardware: Linux Linux
: C - Contributions
Assignee: Tim Wickberg
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2020-06-29 07:28 MDT by Matt Williams
Modified: 2021-08-24 03:38 MDT (History)
4 users (show)

See Also:
Site: -Other-
Alineos Sites: ---
Atos/Eviden Sites: ---
Confidential Site: ---
Coreweave sites: ---
Cray Sites: ---
DS9 clusters: ---
HPCnow Sites: ---
HPE Sites: ---
IBM Sites: ---
NOAA SIte: ---
NoveTech Sites: ---
Nvidia HWinf-CS Sites: ---
OCF Sites: ---
Recursion Pharma Sites: ---
SFW Sites: ---
SNIC sites: ---
Tzag Elita Sites: ---
Linux Distro: CentOS
Machine Name:
CLE Version:
Version Fixed:
Target Release: ---
DevPrio: ---
Emory-Cloud Sites: ---


Attachments
pmix/ucx rpm spec fix (618 bytes, patch)
2021-08-11 21:43 MDT, Carlos Bederian
Details | Diff

Note You need to log in before you can comment on or make changes to this ticket.
Description Matt Williams 2020-06-29 07:28:49 MDT
I am trying to build Slurm 20.02.3 using rpmbuild on the opensuse Build Service. There is a line in the spec which fixes the version of pmix that slurmd depends on based on the version of the pmix package installed:

  %global pmix_version %(rpm -q pmix --qf "%{VERSION}")

However (at least on the version of rpmbuild used on the OBS), when reading this line it is interpreting "%{VERSION}" as wanting to interpolate and replace the string with the defined macro %{version}. From my reading of the RPM docs, variable lookups are case-insensitive so this makes some sense.

The result of this is that the line gets turned into:

  %global pmix_version %(rpm -q pmix --qf "20.02.3")

which returns simply "20.02.3", meaning that later on when the pmix requirement is set it does:

  Requires: pmix = %{pmix_version}

i.e.

  Requires: pmix = 20.02.3

when it should be, e.g. 3.1.5.


I have found that this ambiguity can be resolved by changing the pmix_version definition line to:

  %global pmix_version %(rpm -q pmix --qf "%{RPMTAG_VERSION}")

The same logic probably applies to ucx but I haven't tested that.
Comment 1 Chris Coates 2021-03-15 04:14:25 MDT
Just adding in a me too on this.

I can confirm that the same workaround in the spec file for ucx_version also works.

Tested on 20.02.6, CentOS 8.2.
Comment 2 Carlos Bederian 2021-08-11 21:43:19 MDT
Created attachment 20792 [details]
pmix/ucx rpm spec fix
Comment 3 Carlos Bederian 2021-08-11 21:44:19 MDT
I've also run into this bug. %{VERSION} should be escaped to %%{VERSION} so it doesn't get replaced as a macro.
Comment 4 Oriol Vilarrubi 2021-08-24 03:34:21 MDT
Hi,

We will be fixing this in bug11973, marking this a duplicate.
Comment 5 Oriol Vilarrubi 2021-08-24 03:38:09 MDT
Marking as duplicate

*** This ticket has been marked as a duplicate of ticket 11973 ***