-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SuSE sles15.4: small correction for munge.spec #134
Comments
Hi Frank. Thanks for the changes. The project specfile targets RHEL. The pragmatic reason for this choice is that's what we run in production, and distros will always use their own custom specfile. In practice, the systems on which I currently test the specfile include AlmaLinux 8+, CentOS 7+, CentOS Stream, the last several Fedora releases, and the RHEL versions we run in production. Those are similar enough that I've been able to do so with minimal changes. In the past, I've tried having the specfile support openSUSE as well but had to contend with multiple %if-blocks between releases. The maintenance became too burdensome. But if I have time, I'll try to revisit this and see what would be involved in supporting openSUSE again (which I think should also work on SLES). I just checked my vm systems and openSUSE 15.4 & 15.5 are both at munge-0.5.15. I don't have any SLES systems on which to test (and as such can't readily support it). Re: your changes, |
Hi Chris,
Indeed the specfile in wriiten in excellent way. Only things I did was two zypper – queries and just the minor change in munge.spec. I happy if could make a very little contribution. Many thanks for keeping the munge project running!
SuSE SLES use different names than openSUSE for several RPMs.
At the moment I’m bit busy with our new cluster, but in ~4 weeks I check to change the spec with %if clauses to operate with SuSE.
From perspective the ticket can be closed. I’ll open a new referring to #134 when I upload a change request.
Cheers,
…-Frank
From: Chris Dunlap ***@***.***>
Sent: Thursday, 6 July 2023 01:41
To: dun/munge ***@***.***>
Cc: Heckes, Frank ***@***.***>; Author ***@***.***>
Subject: Re: [dun/munge] SuSE sles15.4: small correction for munge.spec (Issue #134)
Hi Frank. Thanks for the changes.
The project specfile targets RHEL. The pragmatic reason for this choice is that's what we run in production, and distros will always use their own custom specfile. In practice, the systems on which I currently test <https://github.com/dun/munge/blob/master/tests/1000-chaos-rpm.t> the specfile include AlmaLinux 8+, CentOS 7+, CentOS Stream, the last several Fedora releases, and the RHEL versions we run in production. Those are similar enough that I've been able to do so with minimal changes.
In the past <b0f993f> , I've tried having the specfile support openSUSE as well but had to contend with multiple %if-blocks between releases. The maintenance became too burdensome. But if I have time, I'll try to revisit this and see what would be involved in supporting openSUSE again (which I think should also work on SLES).
I just checked my vm systems and openSUSE 15.4 & 15.5 are both at munge-0.5.15. I don't have any SLES systems on which to test (and as such can't readily support it). Re: your changes, libzip5 and libzip-devel are not the same as bzip2-devel; on openSUSE, it's called libbz2-devel.
—
Reply to this email directly, view it on GitHub <#134 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/APDMBS3ZMMQL3TE4TGD73GTXOX3PZANCNFSM6AAAAAAZ4OMZ3Y> .
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Hello, many for the excellent application.
While trying to compile (gcc, gcc-c++,... version 7.5.0) on SuSE sles15.4 the following changes had to made to succeed to run rpmbuild:
zypper install --no-recommends gpg2 libzip5 libzip-devel
gnupg2 --> gpg2
bzip2-devel --> (libzip5 libzip-devel)
to set this into effect, I manually changed the munge.spec. Diff reads as:
-~/software/munge-0.5.15 # diff munge.spec munge.spec-20230703
24c24
< BuildRequires: gpg2
Cheers,
-Frank Heckes
The text was updated successfully, but these errors were encountered: