On Mon, 2013-01-28 at 19:44 +0000, Richard W.M. Jones wrote: > DEBUG util.py:264: Error: Package: 2:qemu-system-mips-1.3.0-5.fc19.x86_64 (build) > DEBUG util.py:264: Requires: libseccomp.so.1()(64bit) > DEBUG util.py:264: Error: Package: 2:qemu-system-or32-1.3.0-5.fc19.x86_64 (build) > DEBUG util.py:264: Requires: libseccomp.so.1()(64bit) > DEBUG util.py:264: Error: Package: 2:qemu-system-microblaze-1.3.0-5.fc19.x86_64 (build) > DEBUG util.py:264: Requires: libseccomp.so.1()(64bit) > [etc] > full log: http://kojipkgs.fedoraproject.org//work/tasks/9474/4909474/root.log > > This seems to have been caused by this build: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=380981 > > Affected packages: > > - libcacard-tools > - qemu So, just as a path for anyone who's interested to take a look down, I think we could potentially Do Something about all these unannounced soname bumps. We do have a test in autoqa that catches them, and doesn't seem to have a huge amount of 'false positives'. The test case is rpmguard, and here is it noticing this soname bump: http://autoqa.fedoraproject.org/resultsdb/frontend/testrun?id_=956918 http://autoqa.fedoraproject.org/results/511987-autotest/virt02.qa/rpmguard/results/libseccomp-2.0.0-0.f.html N: Comparing libseccomp-1.0.1-0.fc19 and libseccomp-2.0.0-0.fc19 (archs: i686) ... W: provision-added libseccomp.so.2 W: provision-removed libseccomp.so.1 N: Comparing libseccomp-1.0.1-0.fc19 and libseccomp-2.0.0-0.fc19 (archs: x86_64) ... W: provision-added libseccomp.so.2()(64bit) W: provision-removed libseccomp.so.1()(64bit) now rpmguard does various other things, so we'd need to filter out the provision-removed (especially) results for this case. But we do at least have this information being captured by autoqa, I think. That's all I got! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
