#3584 PR merged: Remove deprecated BuildRoot tag from RPM spec file

Labels: cleanup

copilot-swe-agent opened issue at 2026-03-16 08:19:

Modern Python specfile library (used in OBS/CI) rejects the BuildRoot: tag when the shell expansion %(mktemp -ud ...) evaluates to empty at parse time, causing ValueError: can't parse specfile.

Changes

  • packaging/rpm/rear.spec: Remove BuildRoot: tag and its associated comment. This tag was only required for SLES 11 / RHEL/CentOS 5 (both long EOL). Modern RPM manages the build root automatically; %{buildroot} in %install continues to work without it.

💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.

pcahyna commented at 2026-03-16 08:35:

@gdha sure. By the way, have you initiated this? (I am not using Copilot myself.)

gdha commented at 2026-03-16 10:19:

@gdha sure. By the way, have you initiated this? (I am not using Copilot myself.)
Yes, asked Copilot to assist me.

jsmeix commented at 2026-03-16 11:14:

I guess this one is needed
to fix current failing checks as in
https://github.com/rear/rear/pull/3579
where e.g.
https://download.copr.fedorainfracloud.org/results/packit/rear-rear-3579/srpm-builds/10230231/builder-live.log.gz
shows

2026-03-16 10:48:29.156 utils.py          ERROR  line 24: Empty tag: BuildRoot:
Traceback (most recent call last):
  File "/usr/lib/python3.14/site-packages/specfile/spec_parser.py", line 237, in get_rpm_spec
    return rpm.spec(tmp.name, flags)
           ~~~~~~~~^^^^^^^^^^^^^^^^^
ValueError: can't parse specfile

pcahyna commented at 2026-03-16 11:47:

@gdha looks good - just please rebase and force-push to drop the first empty commit.

By the way, the Packit CI is not running on it, any idea why? I hoped that it would show a success.

pcahyna commented at 2026-03-16 11:50:

/packit copr-build

pcahyna commented at 2026-03-16 12:25:

/packit copr-build

jsmeix commented at 2026-03-16 12:35:

@pcahyna
out of curiosity:

What is the reason/meaning of your
https://github.com/rear/rear/pull/3584#issuecomment-4067101269
and
https://github.com/rear/rear/pull/3584#issuecomment-4067290252
comments?

My guess is that it is perhaps a command to some bot because
packit-as-a-service[bot] reacted with eyes emoji ?

pcahyna commented at 2026-03-16 12:43:

@pcahyna out of curiosity:

What is the reason/meaning of your #3584 (comment) and #3584 (comment) comments?

My guess is that it is perhaps a command to some bot because packit-as-a-service[bot] reacted with eyes emoji ?

Indeed. I would like to have CI results on this and for some reason unknown to me the CI runs were not started automatically. https://packit.dev/docs/retriggering

jsmeix commented at 2026-03-16 13:22:

Regarding "rebase other stuff on top of it"
in the above comment:

At least for making the failed test work
in other pull requests a rebase is not needed.

E.g. in
https://github.com/rear/rear/pull/3579
I only went to something like
https://github.com/rear/rear/pull/3579/checks?check_run_id=67232990170
where I could "Re-run" the failed checks.
I did not rebase this pull request.
I only triggered "Re-run" for the failed checks
and now the failed checks succeed.

I did the same for
https://github.com/rear/rear/pull/3583

pcahyna commented at 2026-03-16 13:56:

At least for making the failed test work in other pull requests a rebase is not needed.

E.g. in #3579 I only went to something like https://github.com/rear/rear/pull/3579/checks?check_run_id=67232990170 where I could "Re-run" the failed checks. I did not rebase this pull request. I only triggered "Re-run" for the failed checks and now the failed checks succeed.

Ah. That's unexpected at a first glance, but most likely it is because the Packit CI works by first merging the PR branch with the target branch and then executing on the merge commit rather than on the tip of the PR branch. https://packit.dev/docs/configuration/#merge_pr_in_ci . This ensures that the current changes work properly with the master branch, but otherwise it is quite surprising and I don't like it that much. For example, if the master branch breaks something, the PR author can spend time debugging CI failures that are not caused by anything in the PR, if the PR is not up to date and does not contain the cause of problem yet.

[Export of Github issue for rear/rear.]