Red Hat Bugzilla – Bug 1303319
BuildError: Failed to obtain srpm from dist-git
Last modified: 2016-02-01 03:25:01 EST
Description of problem: A package ftp://libvirt.org/libvirt/libvirt-1.3.1-1.fc23.src.rpm builds for epel-6-x86_64 without errors in local mock chroot but not in copr repo (https://copr.fedorainfracloud.org/coprs/dexpl/libvirt-epel6/). According to https://copr-be.cloud.fedoraproject.org/results/dexpl/libvirt-epel6/epel-6-x86_64/build-00157024.log, [2016-01-30 18:11:12,980][ ERROR][PID:31482] Failed to obtain srpm from dist-git Traceback (most recent call last): File "/usr/share/copr/backend/mockremote/builder.py", line 209, in download_job_pkg_to_builder self.remote_pkg_path = list(results["contacted"].values())[0][u"stdout"].split("Wrote: ")[1] IndexError: list index out of range occurs. Neither specifying SRPM URL nor uploading SRPM works.
I managed to narrow the problem down to: copr@coprbox /tmp/build_package_repo/libvirt $ fedpkg-copr --dist el6 srpm error: line 1800: Trigger fired by the same package is already defined in spec file: %post daemon-config-network error: query of specfile /tmp/build_package_repo/libvirt/libvirt.spec failed, can't parse Could not execute srpm: Could not get n-v-r-e from '\n\n' (after doing rm -rf /tmp/build_package_repo && mkdir /tmp/build_package_repo && cd /tmp/build_package_repo && git clone http://copr-dist-git.fedorainfracloud.org/git/clime/example/libvirt.git && cd libvirt && git checkout 64ac67bee7e3ad00f70369a184497ec7d18d7a25) There is some problem with libvirt.spec file parsing when --dist el6 for fedpkg-copr cmd is enabled. This is just an observation, I'll try to find out more.
The problem is in spec file. When you run fedpkg with -d and -v and then try to bisect and minimaze the options. Then you get this minimal reproducer: rpm --define 'rhel 6' --eval '%undefine fedora' -q --specfile /tmp/libvirt/libvirt.spec chyba: line 1800: Trigger fired by the same package is already defined in spec file: %post daemon-config-network I tried to look into libvirt.spec, but that file is so complicated. So it is either spec problem or some bug in RPM itself. I strongly suspect the first one. And I recommend you to post it to RPM mailing list to get hint what can be wrong in your spec file.