https://bugzilla.redhat.com/show_bug.cgi?id=1816301 --- Comment #50 from Benson Muite <benson_muite@xxxxxxxxxxxxx> --- >> a) In the spec file, can you change >> Prefix: /usr/lib/openfoam >> to >> Prefix: %{_libdir}/openfoam > OK to leave as is? > With the %{_libdir} macro it would expand to /usr/lib64 on openSUSE (for example), since their site CONFIG_SITE has %{_lib} as lib64 > for x86_64. > I'd prefer to have a fixed/known install location, and also reuse as much as of the spec as possible for both targets. Probably adding an if statement is preferable if the behavior on OpenSUSE should differ. Otherwise an exemption is needed: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_multilib_exempt_locations >> b) Please also change >> Release: 240429%{?dist} >> to >> Release: 1%{?dist} >> >> This is used to indicate changes in the spec file, for example due to >> rebuilds or changes >> to other options when the sources are not changed. It is independent of the >> actual release version of the sources. > Interesting. On previous copr builds it seems to ignore the auto increment entirely (but my memory might be foggy), which is why I > forced to have the build date there too. > I can revert back without problem. Interesting, the openSUSE builds > prefer "0" instead of "1" for their Release, which is where they slap > in the special handling. Would "0%{?dist}" also work for Fedora, or > just "1%{?dist}" ? Fedora starts at 1. This is incremented for very spec file change without a corresponding source version change. It is possible to use the %autorelease macro to manage this. See https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/ > With the "1%{?dist}" (or "0%{?dist}") I guess that the previously built versions (with the date as release stamp) will mask out the > revised one. I'll need to see how to fix that I guess. Can bump the epoch if there are many people using the copr build. You could also create a new copr repo, and delete both copr repos once the package is accepted. >> c) In the files listing, please change >> >> %{prefix}/%{projectDir}/COPYING >> %{prefix}/%{projectDir}/README.md >> %{prefix}/%{projectDir}/ThirdParty/README > DONE Thanks. >> d) Is there any way to get wmake to mostly use Fedora specific build flags? > We have provision for passing in extra stuff via the > FOAM_EXTRA_CFLAGS FOAM_EXTRA_CXXFLAGS FOAM_EXTRA_LDFLAGS > environment variables. Just not entirely sure should then be in there > for the spec file... > Something like this? > #----- > %build > # Mimic set_build_flags macro, but with wmake names > %if 0%{?fedora}%{?rhel} > FOAM_EXTRA_CFLAGS="${FOAM_EXTRA_CFLAGS:-%{?build_cflags}}" > FOAM_EXTRA_CXXFLAGS="${FOAM_EXTRA_CXXFLAGS:-%{?build_cxxflags}}" > FOAM_EXTRA_LDFLAGS="${FOAM_EXTRA_LDFLAGS:-%{?build_ldflags}}" > export FOAM_EXTRA_CFLAGS FOAM_EXTRA_CXXFLAGS FOAM_EXTRA_LDFLAGS > %endif This seems better. e) Please name the latest release version openfoam without anything additional see: https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1816301 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%201816301%23c50 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
