I am not sure who is the culprit for this bug, so I decided to open it against yum-builddep, which seems to be the part that should take care of this. Anyway, as far as I have investigated the problem begins to happen when one asks for Koji to build some package which uses the %{?_isa} macro. For this specific bug, I will use the GDB as an example. GDB uses the %{?_isa} macro, as can be seen here: <http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb.spec> So, when the package maintainer requests Koji to build GDB, it will correctly generate the RPM files for each supported architecture, and also a SRPM file for it. However, the SRPM file will not be "architecture-agnostic", and the list of build dependencies (assembled from the BuildRequires) will differ depending on the machine we use to build the SRPM. As an example, I have this pristine F20 PPC64 machine here, and when I issue a "yum-builddep gdb" on it, here is what I get: Getting requirements for gdb-7.6.50.20130731-16.fc20.src --> 3:texlive-collection-latexrecommended-svn31071.0-5.20131226_r32488.fc20.noarch --> texinfo-tex-5.1-4.fc20.ppc64 --> texinfo-5.1-4.fc20.ppc64 --> Already installed : gettext-0.18.3.2-1.fc20.ppc64 --> flex-2.5.37-4.fc20.ppc64 --> bison-2.7-3.fc20.ppc64 --> Already installed : perl-podlators-2.5.1-291.fc20.noarch Error: No Package found for expat-devel(armv7hl-32) Error: No Package found for libselinux-devel(armv7hl-32) Error: No Package found for ncurses-devel(armv7hl-32) Error: No Package found for python-devel(armv7hl-32) Error: No Package found for readline-devel(armv7hl-32) >= 6.2-4 Error: No Package found for rpm-devel(armv7hl-32) Error: No Package found for xz-devel(armv7hl-32) Error: No Package found for zlib-devel(armv7hl-32) So I was asking myself "why would this SRPM depend on ARM devel packages when I am on PPC64?" The answer came when I looked at the Koji build logs. You can see that the SRPM for this specific GDB build (gdb-7.6.50.20130731-16.fc20) was generated by an ARM machine: <http://koji.fedoraproject.org/koji/buildrootinfo?buildrootID=1906872> Therefore, it is expecting that we install the ARM version of the packages. This is obviously wrong, so I would like to ask you to fix this. Please let me know if you need more information, or if you think this is someone else's problem.
FWIW, this issue has also been found when using Coverity Scan, and it has been fixed in the upstream project by this commit: <https://git.fedorahosted.org/cgit/csmock.git/commit/?id=80d85287>
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.