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/f...
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.