i've created a custom macro file, packaged as a COPR pkg ( pgfed/pgnd-rpmbuild-macros ), for reference/(re)use in my _other_ COPR builds. it contains a macro def'n, "%_pgnd_macros"
if I install the pkg locally,
rpm -ql pgnd-rpmbuild-macros /usr/lib/rpm/macros.d /usr/lib/rpm/macros.d/macros.pgnd-rpmbuild
and reference it in a test.spec
cat test.spec
%{_pgnd_macros}
Name: test Release: %{dist} Summary: test License: MIT Version: 1 BuildArch: noarch
%description ...
any/all of its macro defs/expansions are available, as intended, and can be used throughout the build. same for local mock builds.
next, to get my COPR builds to use it, @ COPR: Home >> pgfed >> [project] >> Settings >> Project Details
, i've set:
External Repositories: copr://pgfed/pgnd-rpmbuild-macros/fedora-$releasever-$basearch/
and, for the specific buildroot, @ COPR: Home >> pgfed >> [project] >> Edit >> fedora-32-x86_64
, i've set:
Packages: git coreutils rpm pgnd-rpmbuild-macros
once save, @ the project Overview,
External Repository List The following repositories are accessible during builds copr://pgfed/pgnd-rpmbuild-macros/fedora-$releasever-$basearch/
On build exec @ COPR, the build fails
... stderr: error: line 1: Unknown tag: %{_pgnd_macros} can't parse specfile
here's a specific example,
https://copr.fedorainfracloud.org/coprs/pgfed/redis-6/build/1601289/ https://download.copr.fedorainfracloud.org/results/pgfed/redis-6/srpm-builds...
what additional/changed config is required to get my 'other' COPR builds to correctly include/use my DIY-macros?
On Tuesday, August 11, 2020 2:47:19 AM CEST PGNet Dev wrote:
stderr: error: line 1: Unknown tag: %{_pgnd_macros} can't parse specfile
here's a specific example,
https://copr.fedorainfracloud.org/coprs/pgfed/redis-6/build/1601289/ https://download.copr.fedorainfracloud.org/results/pgfed/redis-6/srpm-builds...
what additional/changed config is required to get my 'other' COPR builds to correctly include/use my DIY-macros?
Usually it is enough to use '%{?_pgnd_macros}' variant (see the question mark). For the purpose of generating source RPM, the macros aren't usually needed.
In Copr, the additional buildroot packages (you specified) don't affect the source RPM buildroot (there's no custom control of the source RPM buildroot yet in Copr, you can not even decide what fedora version it should be based on).
Btw., similar problems happen all the time even in Koji, because BuildRequires are often specified to bring-in build-time macros; but at srpm build time there are no BuildRequries installed (compared to the binary RPMs build time).
Pavel
On 8/10/20 10:47 PM, Pavel Raiskup wrote:
Usually it is enough to use '%{?_pgnd_macros}' variant (see the question mark). For the purpose of generating source RPM, the macros aren't usually needed.
using
- '%{pgnd_macros}'
+ '%{?_pgnd_macros}'
the build does NOT fail for the reason the macro file itself isn't found
but the build still FAILs because the macros it's supposed to provide aren't found.
e.g.,
https://download.copr.fedorainfracloud.org/results/pgfed/redis-6/srpm-builds...
On Tuesday, August 11, 2020 5:28:16 PM CEST PGNet Dev wrote:
On 8/10/20 10:47 PM, Pavel Raiskup wrote:
Usually it is enough to use '%{?_pgnd_macros}' variant (see the question mark). For the purpose of generating source RPM, the macros aren't usually needed.
using
- '%{pgnd_macros}'
- '%{?_pgnd_macros}'
the build does NOT fail for the reason the macro file itself isn't found
but the build still FAILs because the macros it's supposed to provide aren't found.
e.g.,
https://download.copr.fedorainfracloud.org/results/pgfed/redis-6/srpm-builds...
It actually succeeded, but copr failed to further work with that src.rpm over http protocol through AWS caching because of the special characters in URL -- it was caused by unexpanded macro (I deduce):
stderr: warning: line 36: Possible unexpanded macro in: Release: %{_forge_dist}
Perhaps the %_forge_dist macro needs to be used with question mark as well? Similarly to how the %dist macro is used?
Release: 1%{?dist} => Release: 1%{?_forge_dist}
But I don't know; I never used it.
Pavel
On 8/11/20 11:08 AM, Pavel Raiskup wrote:
Perhaps the %_forge_dist macro needs to be used with question mark as well? Similarly to how the %dist macro is used?
Release: 1%{?dist} => Release: 1%{?_forge_dist}
But I don't know; I never used it.
noted.
I'm not sure why that should be expected to work. There's no fallback ... and, in this case, i expect/require that %{_forge_dist} is def'd. Exactly as it does in the local mock env.
In any case, if I change in the spec
- %global dist %{?_forge_dist} + %global dist %{?_forge_dist}
Name: %{_redis_name} 36 Release: %{dist}
The build fails again, but now at
stderr: error: line 36: Empty tag: Release: can't parse specfile
I'm stymied as to why COPR build -- which I understood to be a mock env? -- behaves significantly differently than a local mock build.
On Tuesday, August 11, 2020 8:31:59 PM CEST PGNet Dev wrote:
On 8/11/20 11:08 AM, Pavel Raiskup wrote: > > Perhaps the %_forge_dist macro needs to be used with question mark as well? stderr: error: line 36: Empty tag: Release: can't parse specfile
Release can never consist of only the %dist tag. The %dist tag is only a suffix after the actual release value.
I'm stymied as to why COPR build -- which I understood to be a mock env? -- behaves significantly differently than a local mock build.
It _is_ (wrapped) mock env. But copr fails at generating the source.rpm _from sources you provide_. (it later imports that source RPM to its own dist-git, and re-builds the source RPMs in target buildroots once more).
The first source.rpm (or a source) build is not what you are doing in mock, right? I suppose you just generate the initial source RPM by on-host `rpmbuild -bs` call (before you give the source RPM to mock). Copr does similar thing on builder, but inside mock - with 'default.cfg' (and that config is not (yet), as I claimed, possible to configure in Copr).
If I'm right on what you are really doing; and if you want to experience the same situation as is now in Copr, uninstall the macro package from your host system before you do `rpmbuild -bs` on host. If you really need the macros at source RPM (which I'd advice against), please fill an RFE against Copr (it could be implemented, I think). Though such things are really, really unlikely to work in Fedora default buildsystem - Koji. The Fedora rule is (a) either get the macro package into the minimal buildroot (which basically means you have to enhance the redhat-rpm-config package, or (b) don't rely on the macros at source RPM build time at all (use %{?..} macro variant everywhere), and put the macro package to BuildRequires.
Pavel
On 8/11/20 12:16 PM, Pavel Raiskup wrote:
On Tuesday, August 11, 2020 8:31:59 PM CEST PGNet Dev wrote:
On 8/11/20 11:08 AM, Pavel Raiskup wrote: > > Perhaps the %_forge_dist macro needs to be used with question mark as well? stderr: error: line 36: Empty tag: Release: can't parse specfile
Release can never consist of only the %dist tag. The %dist tag is only a suffix after the actual release value.
it does in _all_ my other builds, without any problem. either locally, or at COPR.
e.g.,
https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedo...
wherein, I've re-def'd dist as,
%global dist %{_owner}_%{_build_timestamp}.fc%{fedora}
which is required after (multiple) forgemeta expansions, since fm mungs the dist value through multiple concats.
I'm stymied as to why COPR build -- which I understood to be a mock env? -- behaves significantly differently than a local mock build.
It _is_ (wrapped) mock env. But copr fails at generating the source.rpm _from sources you provide_. (it later imports that source RPM to its own dist-git, and re-builds the source RPMs in target buildroots once more).
The first source.rpm (or a source) build is not what you are doing in mock, right? I suppose you just generate the initial source RPM by on-host `rpmbuild -bs` call (before you give the source RPM to mock). Copr does similar thing on builder, but inside mock - with 'default.cfg' (and that config is not (yet), as I claimed, possible to configure in Copr).
If I'm right on what you are really doing; and if you want to experience the same situation as is now in Copr, uninstall the macro package from your host system before you do `rpmbuild -bs` on host. If you really need the macros at source RPM (which I'd advice against), please fill an RFE against Copr (it could be implemented, I think). Though such things are really, really unlikely to work in Fedora default buildsystem - Koji. The Fedora rule is (a) either get the macro package into the minimal buildroot (which basically means you have to enhance the redhat-rpm-config package, or (b) don't rely on the macros at source RPM build time at all (use %{?..} macro variant everywhere), and put the macro package to BuildRequires.
i clearly need to re-read/re-think all that^
what I'm "really doing" is putting a .spec file in my pagure.io account, and hoping to get that built ... from spec ... @ COPR, thru pagure->copr 'integration'.
it works perfectly in all cases ... except/until I 'simply' want to stop wasting bits replicating the same macro expansions for each & every build (and making the mistakes/typos that go along with it!), and, instead, make the often-re-used macro expansions available ONCE, in a COPR package, and have my COPR builds use it.
Dne 11. 08. 20 v 20:31 PGNet Dev napsal(a):
On 8/11/20 11:08 AM, Pavel Raiskup wrote:
Perhaps the %_forge_dist macro needs to be used with question mark as well? Similarly to how the %dist macro is used?
Release: 1%{?dist} => Release: 1%{?_forge_dist}
But I don't know; I never used it.
noted.
I'm not sure why that should be expected to work. There's no fallback ... and, in this case, i expect/require that %{_forge_dist} is def'd. Exactly as it does in the local mock env.
In any case, if I change in the spec
- %global dist %{?_forge_dist}
This ^^might be undefined if `%{_forge_dist}` does not exists. You should use some fallback, e.g.:
~~~
%global dist %{?_forge_dist}%{!?_forge_dist:fallback_dist}
~~~
Vít
%global dist %{?_forge_dist}
Name: %{_redis_name}
36 Release: %{dist}
The build fails again, but now at
stderr: error: line 36: Empty tag: Release: can't parse specfile
I'm stymied as to why COPR build -- which I understood to be a mock env? -- behaves significantly differently than a local mock build. _______________________________________________ buildsys mailing list -- buildsys@lists.fedoraproject.org To unsubscribe send an email to buildsys-leave@lists.fedoraproject.org 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/buildsys@lists.fedoraproject.o...
buildsys@lists.fedoraproject.org
-
Pavel Raiskup -
PGNet Dev -
Vít Ondruch