Red Hat Bugzilla – Bug 349801
mock installs packages that don't satisfy BuildRequires:
Last modified: 2014-01-21 17:59:58 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) Gecko/20070718 Fedora/220.127.116.11-1.fc7 Firefox/18.104.22.168
Description of problem:
When trying to build arpack, which has
mock finds that atlas-devel satisfies that BR, when it doesn't. At least, according to yum resolvedep on F-7:
yum resolvedep /usr/lib64/liblapack.so
Loading "basearchonly" plugin
Loading "fastestmirror" plugin
Loading mirror speeds from cached hostfile
Importing additional filelist information
Fails consistently for dist-f9, dist-f8-updates-candidate and dist-fc7-updates-candidate scratch builds:
Version-Release number of selected component (if applicable):
whatever is running on koji
Steps to Reproduce:
1. wget http://rathann.fedorapeople.org/review/arpack-2.1-7.fc7.src.rpm
2. koji build --scratch dist-f9 arpack-2.1-7.fc7.src.rpm
Build fails with:
/usr/bin/ld: cannot find -llapack
arpack should build successfully, as it does for local builds with lapack-devel installed.
This looks like it could possibly be a bug in FC6 yum, which is what mock uses
to resolve the deps.
We will be investigating this. In the mean time a workaround would be to setup
an %if structure to buildrequire the actual package name for Fedora and for RHEL.
http://fedoraproject.org/wiki/Packaging/DistTag has info on how you can do this.
This is fixed in Fedora 7 onwards.
Yes, but I'm the buildsys is still running FC6 and that is the problem, so
please don't just close the bug like that. I cannot upgrade the OS which is
running on the buildsys, so this bug remains open as far as I'm concerned,
because it prevents us from building a perfectly valid package.
The bug is still present, please fix it already...
Why don't you just update buildsys' mock?
In reply to comment #4)
> Why don't you just update buildsys' mock?
I meant, of course, yum.
Reassigning to infrastructure and bumping up severity. This is preventing a new,
perfectly valid package from entering Fedora.
Cc'ing Axel. It's his package that trigger this problem.
FC6 is EOL, and yum development usually does not support too old yum versions.
Could we please get a newer yum on the builders? Or maybe a backport of the fix
to the yum version used there? Thanks!
the entire buildsys was updated to RHEL5 in early december: mock 0.9, yum 3.0
Has this been confirmed to still be a problem?
Yes, it still seems to be a problem to me. (I happen to really need arpack.)
See the following task: http://koji.fedoraproject.org/koji/taskinfo?taskID=381895
This builds fine in local mock (mock 0.9.5 running on Fedora 8, the build is
against rawhide) but in koji it fails. The important difference is in root.log:
on my system, mock (or yum, I guess) figures out that it needs to install
lapack-devel to satisfy the dependency on liblapack.so; in koji, it doesn't.
Note the following in the spec, though:
# The correct dependency would be the following, but it doesn't exist on RHEL4/3
This trouble could probably be worked around simply by conditionalizing the
BuildRequires:, or just not using the same spec on RHEL4.
(In reply to comment #9)
> the entire buildsys was updated to RHEL5 in early december: mock 0.9, yum 3.0
> Has this been confirmed to still be a problem?
Yes, shortly before posting comment #8.
(In reply to comment #10)
> This trouble could probably be worked around simply by conditionalizing the
> BuildRequires:, or just not using the same spec on RHEL4.
Not really, we are just seeing an implementation of some bug that seems to
invent provides of a package where there are none. Papering over the triggering
case will not make the bug go away, on the contrary we do need this package in
the form it is, not just because it is written correctly, but because otherwise
you will need to wait for some other package to trigger this bug.
E.g. Michael, if you do have direct access to the buildsys then please use this
package to diagnose yum and friends on why they decide to do things differently
there than in our local setups. Thanks!
It's still hilarious that this hasn't been built yet when the workaround is
trivial; not having this built serves no useful purpose and merely blocks other
packages from entering the distro (and screws me into having to maintain the
packages in a local distro for no rational reason whatsoever). People know that
some updates need to be made on the builders but this requires coordination and
maintainer time, while the workaround requires essentially no time from anyone.
The fixes will happen in the course of time anyway so the thought that leaving
arpack unbuilt somehow places pressure on someone to revise the update schedule
However, I heard that some updates were occurring on the builders today and I
did a scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=428390
It succeeded on one host but failed on another; I asked for the yum versions on
the relevant hosts and was told that ppc4 has yum-3.2.8-6.el5 while ppc3 has
only yum-3.0.1-5.el5. With luck the other builders will be likewise updated and
this sad saga can come to a close.
All of the builders have been updated; arpack builds fine now: