#2816 PR merged
: RPM spec: update build requirement for Fedora to unblock Packit build and run make validate after build¶
Labels: enhancement
, fixed / solved / done
, ReaR Project
antonvoznia opened issue at 2022-06-04 14:22:¶
Relax-and-Recover (ReaR) Pull Request Template¶
Please fill in the following items before submitting a new pull request:
Pull Request Details:¶
-
Type: Enhancement
-
Impact: Low
-
Reference to related issue (URL): https://github.com/rear/rear/issues/2757
-
How was this pull request tested?
Test with correct filenames and a little change with no impact:
https://github.com/antonvoznia/rear/pull/51
As result the packit build has been passed
https://dashboard.packit.dev/results/copr-builds/362145
Test with incorrect filename:
https://github.com/antonvoznia/rear/pull/52
As result the Packit build has been failed:
https://dashboard.packit.dev/results/copr-builds/362146
- Brief description of the changes in this pull request:
Adding make validate for building stage to check the correctness of the filenames of the scripts.
It is instead of travis CI solution which were actual in past.
pcahyna commented at 2022-06-06 09:00:¶
Some context - Packit builds were configured in PR #2145 , and this was a long time ago, so contributors may have forgotten what it is. Packit is a service which does automatic rebuilds of RPMs from the GitHub Git sources. If enabled on PRs, it can serve as a CI (to ensure that the change does not break the build and also optionally run some tests).
The original PR #2145 mentions that " the main packit task is to update Fedora package with the latest upstream releases", but this part has not been configured here. This addresses the concern arising back then about "building a released ReaR version versus building our current (possibly unstable work-in-progress) upstream master code" - we are not going to blindly sync the upstream master branch to Fedora, don't worry.
You may notice that there is no build information about any build or test made by Packit attached to this PR. That's because the Packit-as-a-service application that performs the builds triggered by any PRs has not been enabled on the ReaR repo. I'll enable it shortly (unless there is an objection from @rear/contributors) - without it, the Packit configuration is not really useful. (What actually happened is that without the builds enabled, the Fedora build stopped working as the spec file bitrot - that's the reason for one of the commits which adds BuildRequires. The PR is a bit misnamed since the added requirement to spec file is not just for Packit - it is for any Fedora build, Packit is merely a build service that exposes the problem.)
For now, until the service is enabled, the linked PRs in @antonvoznia 's repo show how will a successful build and a failing build look like.
pcahyna commented at 2022-06-06 09:27:¶
One may note that this PR does not touch anything Packit-specific.
That's right - packit has been configured already, so this PR fixes and
then enhances (by adding the %check
section to run make validate
)
the spec file that can be used to build Fedora packages anywhere (not
just in Packit).
@jsmeix can you please verify that the change does not break
openSUSE/SLES builds, as the same spec file is used for them and for
Fedora? Maybe Packit could be used to test builds for openSUSE as well,
since in COPR (the build service used by Packit) I see the possibility
of building in these buildroots:
opensuse-leap-15.2-aarch64 opensuse-leap-15.2-x86_64 opensuse-leap-15.3-aarch64 opensuse-leap-15.3-x86_64 opensuse-tumbleweed-aarch64 opensuse-tumbleweed-i586 opensuse-tumbleweed-ppc64le opensuse-tumbleweed-x86_64
.
Would any of them be useful?
jsmeix commented at 2022-06-07 08:34:¶
@pcahyna
normally the openSUSE Build Service should "just build" anything
with a regular RPM spec file so with a %check
section that calls
something in a "normal" way the package should still "just build".
If not we can further adapt things as needed.
pcahyna commented at 2022-06-07 15:50:¶
@jsmeix I think it will be useful if Packit builds also RPMs for openSUSE if it is able to. This way we will know immediately when the builds start failing. As I am not familiar with openSUSE versioning and requirements, which builds among opensuse-leap-15.2-aarch64 opensuse-leap-15.2-x86_64 opensuse-leap-15.3-aarch64 opensuse-leap-15.3-x86_64 opensuse-tumbleweed-aarch64 opensuse-tumbleweed-i586 opensuse-tumbleweed-ppc64le opensuse-tumbleweed-x86_64 should I enable?
pcahyna commented at 2022-06-07 16:01:¶
I would like to enable Packit on the repository so that the configuration is actually useful. But it looks that only organization owners can do this. @gdha could you please enable it according to the instructions in https://packit.dev/docs/packit-service/#integrating-packit-as-a-service-into-your-project-or-organization-from-github-marketplace ? I see you have a FAS (Fedora) account that Packit requires: https://packit.dev/docs/packit-service/#requirements-for-running-packit-service-jobs
gdha commented at 2022-06-07 19:26:¶
@pcahyna Packit has been linked to the ReaR project now.
jsmeix commented at 2022-06-08 07:12:¶
@pcahyna
I think to only see when the builds start failing
it should be sufficient to let it build only on
opensuse-leap-15.3-x86_64 and
opensuse-tumbleweed-x86_64
My reasoning:
The openSUSE Leap base system is inherited from
SUSE Linux Enterprise 15 (SLE15)
so the openSUSE Leap base system is rather traditional.
In contrast openSUSE Tumbleweed is a rolling release
of more or less the latest available software versions.
Because ReaR is only bash scripts building should not depend
on hardware architectures so I think only x86_64 is sufficient.
On the other hand to provide binary RPM packages
which openSUSE users can install with rpm
on their systems
one may have to build it for all available openSUSE systems
(regardless that ReaR is only bash scripts).
The reason is that different rpm
versions in different
openSUSE versions may produce different binary RPM packages
so whether or not a binary RPM package can be installed
on an openSUSE version can depend on which openSUSE version
the binary RPM package was built.
For example RPM's internal data compression method may differ
so a binary RPM package that was built on a newer openSUSE version
could not be installed with rpm
on an older openSUSE version
(because an older rpm
may not support a new compression method).
pcahyna commented at 2022-06-08 07:15:¶
/packit build
jsmeix commented at 2022-06-09 11:16:¶
In
https://github.com/rear/rear/pull/2819
I added the changes of this pull request there via
https://github.com/rear/rear/pull/2819/commits/87ddeeaed6f225005ae19998fece6f1d5366eda6
and now the automated Packit build test works there!
So
https://github.com/rear/rear/pull/2819
may obsolete this pull request here
in particluar because there is a comment
in packaging/rpm/rear.spec why that
BuildRequires: make
is there ;-)
pcahyna commented at 2022-06-09 12:59:¶
@jsmeix indeed, Packit builds now work, I have triggered a rebuild on this PR manually. Thank you @gdha for enabling Packit on the repository!
(Now until the spec is fixed (this PR or https://github.com/rear/rear/pull/2819), future PRs will trigger a failing Fedora RPM rebuild.)
pcahyna commented at 2022-06-09 13:00:¶
I will add opensuse-leap-15.3-x86_64 and opensuse-tumbleweed-x86_64 in a separate PR (if they work properly).
pcahyna commented at 2022-06-09 13:27:¶
I will add opensuse-leap-15.3-x86_64 and opensuse-tumbleweed-x86_64 in a separate PR (if they work properly).
They do - https://github.com/pcahyna/rear/pull/7
pcahyna commented at 2022-06-09 14:12:¶
because there is a comment
in packaging/rpm/rear.spec why that
BuildRequires: make
is there
The comment is not entirely correct: any Fedora build now requires a
build dependency on make
, Packit merely exposes the problem.
Anyway, I don't think that an explanation of this dependency is needed.
The build uses make
so it is natural that it needs make
, which is
expressed as a build dependency. It was merely an "accident" that older
versions of Fedora had make
always installed in the buildroot and
therefore an explicit dependency was not needed.
pcahyna commented at 2022-06-09 14:19:¶
@antonvoznia thank you for the PR and for updating it - looks good now, I changed the title to better reflect the intent and if others agree, I will merge it soon.
jsmeix commented at 2022-06-09 16:11:¶
@pcahyna
thank you for your explanation why BuildRequires: make
is a generic thing so no specific comment is needed here.
pcahyna commented at 2022-06-20 08:25:¶
I will add opensuse-leap-15.3-x86_64 and opensuse-tumbleweed-x86_64 in a separate PR (if they work properly).
#2823
[Export of Github issue for rear/rear.]