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/fedora-32-x86_64/01602065-compat-luarocks/compat-luarocks.spec 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. _______________________________________________ buildsys mailing list -- buildsys@lists.fedoraproject.org To unsubscribe send an email to buildsys-le...@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.org
