Hi Tim,
we (kamil and I) briefly went through the log, and althought we did not really find out what's the 'primary cause' of the update's failure, we at least discovered, what do these blocks
SKIPBROKEN: --> Package: erlang-js-0.5.0-2.fc15.x86_64 (f15) --> Requires: libjs.so.1()(64bit) --> Removing: js-1.70-13.fc15.x86_64 (f15) --> libjs.so.1()(64bit) --> Updated By: 1:js-1.8.5-6.fc15.x86_64 (pending) --> Not found [view ยป]
mean. In all the occasions the problem is that the library (the 'js-1.70-13.fc15.x86_64' in this particular example) providing the dynamicaly-linked library (here it is 'libjs.so.1()(64bit)') gets updated, but the new version does not provide the required dependency. This causes a lot of packages to fail, since all the 'broken' packages are removed from pkgsack, and it's done as long as the dependencies are not 'OK'.
As I said, that's not really the root of the problem, but at least, we uncovered one more layer of depcheck's error messages.
J.
----- Original Message -----
From: "Tim Flink" tflink@redhat.com To: "AutoQA development" autoqa-devel@lists.fedorahosted.org Sent: Friday, June 24, 2011 4:47:05 PM Subject: Odd Depcheck Output I was looking through some of the results on the testing instance and I found an ... interesting depcheck log.
http://10.11.230.168/results/13591-autotest/hp-xw9300.test.redhat.com/depche...
I'm still not quite sure what happened here but the only real error that I'm seeing offhand is in qterm even though a lot of builds were failed along with it.
The timing of this isn't great but I'm starting to question the wisdom of the "fix" for #284 [1]. I had not anticipated extranious failures like this and I'm wondering if this is just going to cause more confusion than test results that aren't reported to bodhi.
Thoughts?
Tim
[1] https://fedorahosted.org/autoqa/ticket/284
autoqa-devel mailing list autoqa-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/autoqa-devel