Odd Depcheck Output

[Tim Flink]

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

[Josef Skladanka]

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" 
> To: "AutoQA development" 
> 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
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/autoqa-devel

[Kamil Paral]

> 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

[Tim Flink]

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

[James Laska]

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

[Kamil Paral]

> 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.

[James Laska]

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

[Tim Flink]

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