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
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
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.
I added the description of this problem into
https://fedoraproject.org/wiki/AutoQA_tests/Depcheck#.22Not_Found.22_errors
On 06/27/2011 09:13 AM, Kamil Paral wrote:
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.
I added the description of this problem into
https://fedoraproject.org/wiki/AutoQA_tests/Depcheck#.22Not_Found.22_errors
Cool, thanks.
I'm still looking for more examples to put up there. If anyone knows of good ones, please pass them on.
Tim
On Mon, 2011-06-27 at 18:46 -0600, Tim Flink wrote:
On 06/27/2011 09:13 AM, Kamil Paral wrote:
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.
I added the description of this problem into
https://fedoraproject.org/wiki/AutoQA_tests/Depcheck#.22Not_Found.22_errors
Cool, thanks.
I'm still looking for more examples to put up there. If anyone knows of good ones, please pass them on.
Yeah, nice failure mode ... thanks for adding Kamil.
Do the two suggested resolutions apply for the new "Not found" error? What would a maintainer do in this case?
Thanks, James
On Mon, 2011-06-27 at 18:46 -0600, Tim Flink wrote:
On 06/27/2011 09:13 AM, Kamil Paral wrote:
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.
I added the description of this problem into
https://fedoraproject.org/wiki/AutoQA_tests/Depcheck#.22Not_Found.22_errors
Cool, thanks.
I'm still looking for more examples to put up there. If anyone knows of good ones, please pass them on.
Yeah, nice failure mode ... thanks for adding Kamil.
Do the two suggested resolutions apply for the new "Not found" error? What would a maintainer do in this case?
Should we add something like...
Correct the dependencies If your package failed because the dependencies of other packages changed (features they were providing changed or were removed), update the requirements of your package or consult it with maintainers of the corresponding third-party packages.
On Tue, 2011-06-28 at 10:29 -0400, Kamil Paral wrote:
On Mon, 2011-06-27 at 18:46 -0600, Tim Flink wrote:
On 06/27/2011 09:13 AM, Kamil Paral wrote:
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.
I added the description of this problem into
https://fedoraproject.org/wiki/AutoQA_tests/Depcheck#.22Not_Found.22_errors
Cool, thanks.
I'm still looking for more examples to put up there. If anyone knows of good ones, please pass them on.
Yeah, nice failure mode ... thanks for adding Kamil.
Do the two suggested resolutions apply for the new "Not found" error? What would a maintainer do in this case?
Should we add something like...
Correct the dependencies If your package failed because the dependencies of other packages changed (features they were providing changed or were removed), update the requirements of your package or consult it with maintainers of the corresponding third-party packages.
I made a few adjustments to merge what Tim wrote, with your suggestion. Feel free to adjust/revert as needed.
https://fedoraproject.org/wiki/AutoQA_tests/Depcheck#Fixing_Failures
Thanks, James
On 06/24/2011 08:47 AM, Tim Flink wrote:
I was looking through some of the results on the testing instance and I found an ... interesting depcheck log.
While looking for more depcheck failure examples for our documentation, I've come across two more failures that I can't explain at the moment.
http://autoqa.fedoraproject.org/results/135089-autotest/ - This feels like an "obsoletes" issue between ghc-leksah-server-devel and ghc-prof but I have almost no confidence in that diagnosis.
http://autoqa.fedoraproject.org/results/135237-autotest/
The strange thing I'm seeing here happens pretty quickly: -> Not Updating Package that is already obsoleted: resource- agents.x86_64 0:3.1.1-1.fc15
I'm not sure what's going on but resource-agents fails update (apparantly due to something being obsoleted. Nothing shows up in repoquery, though) and then is successfully updated as a dependency of clusterlib. We then end up with the same package failing and passing (the failure overrides the pass, though).
If anyone wants to figure these out, feel free. I'll start in on them again tomorrow otherwise.
Tim
autoqa-devel@lists.fedorahosted.org
-
James Laska -
Josef Skladanka -
Kamil Paral -
Tim Flink