Hide Forgot
Description of problem: I'm trying to test-build packages against a new version of libpng in a mock chroot, basically by doing this: sudo -u mockbuilder /usr/bin/mock --init -r fedora-rawhide-x86_64 sudo -u mockbuilder /usr/bin/mock -r fedora-rawhide-x86_64 --install /tmp/libpng-*x86_64.rpm sudo -u mockbuilder /usr/bin/mock -r fedora-rawhide-x86_64 --rebuild --no-clean /tmp/<package-srpm> The problem I'm running into is that if any of the BuildRequires for the specified SRPM depend on the old version of libpng (so that "yum install"ing them will fail), mock just breaks completely. It does not install any dependencies, but it tries to launch the build anyway, which of course falls over. And what's worse, so far as I've been able to find it does not log anything at all about the failure. The last line in root.log is something like DEBUG backend.py:765: ['/usr/bin/yum-builddep', '--installroot', '/var/lib/mock/fedora-rawhide-x86_64/root/', '/var/lib/mock/fedora-rawhide-x86_64/root///builddir/build/SRPMS/cups-1.5.0-13.fc17.src.rpm'] which I suppose is failing, but please could we have a useful error message? It appears that --installdeps mode has the same issue. Version-Release number of selected component (if applicable): mock-1.1.14-1.fc14.noarch How reproducible: 100% Steps to Reproduce: 1. Set up an arrangement whereby BuildRequires installation will fail. 2. Try to build. Actual results: No useful diagnostics; misleadingly attempts to do the build even though prerequisite installation failed. Expected results: Report the yum error message and stop without attempting the build step. Additional info:
Tom, Any thoughts/help in setting up reproducer step #1? Maybe a contrived SRPM with a non-existant buildrequire?
[ experiments... ] Hmm, I can no longer reproduce the problem using mock-1.1.15-1.fc14, which is what's on my workstation now. I get a reasonably clear complaint about the conflict in root.log and then it aborts. So looks like 1.1.15 fixed it.
was kinda hoping that; there were fixes to yum-builddeps that probably fixed this. Ok to close?
Sure, as long as your reaction wasn't "hm, nothing should have changed there..."
Nah, I knew we had some builddep problems, but since we use yum-builddeps to figure all that out, my suspicions fell squarely there. That's my story and I'm sticking to it.