bohdi AutoQA: depcheck test FAILED

[Alec Leamas]

On 08/21/2012 07:57 PM, Adam Williamson wrote:
> On 2012-08-21 9:36, Alec Leamas wrote:
>> On 08/21/2012 04:22 PM, Kamil Paral wrote:
>>>> hi,
>>>> i need help, because the AutoQA DepCheck fails on the package
>>>> speed-dreams,but the package was pushed anyway.
>>>> AutoQA DepCheck log:
>>>>
>>>> http://autoqa.fedoraproject.org/results/418027-autotest/virt04.qa/depcheck/results/speed-dreams-2.1.0-1.html 
>>>>
>>>>
>>>> the problem was already discussed on
>>>> http://forums.fedoraforum.org/showthread.php?t=283254&page=2
>>> Depcheck fails, because your x86_64 package requires a dependency 
>>> that is not available:
>>>
>>> $ yum provides 'libenet-1.3.3.so'
>>> Loaded plugins: changelog, langpacks, refresh-packagekit, 
>>> remove-with-leaves, show-leaves
>>> No Matches found
>>>
>>> The package has been pushed just to updates-testing [1]. Please make 
>>> sure it is not pushed to stable updates. Unpush it, fix the 
>>> dependency problem, and then push it to Bodhi again.
>>>
>> Yes, the package is broken and must not end up in stable, agreed.
>>
>> The next question is why. Looking at my own f-17 box, it's obvious
>> that the current state of enet is libenet-1.2.1. This is the same
>> version as in f16.The specfile is not conditionalized in any way.
>> Still, the f16 build Requires: 1.2.1 whereas the f17 wants 1.3.3.
>>
>> Which brings the question: how can the same spec could end up in a
>> build requiring libenet-1.3.3 (in f17) or libenet1.2.1 (in f16), even
>> though the correct version in both cases seems to be libenet-1.2.1?
>> How could anything built on F17 require a non-existing version, using
>> automatic dependencies?
>>
>> I really wish I could understand this, thus becoming a Real Wizard -
>> or, possibly, just not a ...... (place for proper noun)
>
> Well, if you look at the koji logs:
>
> http://kojipkgs.fedoraproject.org//packages/speed-dreams/2.1.0/10.trunk_r4810.fc17/data/logs/x86_64/ 
>
>
> root.log quite clearly shows enet-1.3.3-1.fc17 being installed, not 
> 1.2.1. If we look up enet builds:
>
> http://koji.fedoraproject.org/koji/packageinfo?packageID=5099
>
> we can see there is indeed a 1.3.3 build dating all the way back to 
> March. Finally if we look at Bodhi:
>
> https://admin.fedoraproject.org/updates/FEDORA-2012-3795/enet-1.3.3-1.fc17 
>
>
> we can see that build was pushed stable for Fedora 17 on 14th April.
>
> If you look carefully at the AutoQA log, what actually seems to be 
> happening here is some kind of arch mismatch with the speed-dreams 
> package. This is meant to be a test of the speed-dreams *x86_64* 
> package - but for some reason, when AutoQA tries to install the 
> speed-dreams x86_64 RPM, it also seems to pull in the speed-dreams and 
> speed-dreams *i686* packages. It's the dependency of the *32-bit* 
> speed-dreams package on libenet which isn't being met, because libenet 
> isn't multiarch. So that in itself isn't actually wrong - you'd expect 
> installing the 32-bit speed-dreams on a 64-bit host without 32-bit 
> repos to fail this way. The real question is, why is installing the 
> 64-bit speed-dreams package pulling in the 32-bit one as well? Is this 
> an error in the speed-dreams packaging, or in AutoQA?

Thanks for sorting this out. It's a long way to be a Real Wizard ;)

Following this track: if I look into the build log for the 64-bit f17  
build   [1], it seems  that the package doesn't require anything but the 
libenet-1.3.3(64-bit). So; in my simple eyes, this looks like AutoQA 
doesn't really understand the situation if it says it needs the 32-bit 
version.

[1]http://kojipkgs.fedoraproject.org//packages/speed-dreams/2.1.0/10.trunk_r4810.fc17/data/logs/x86_64/build.log

--alec


Sorry for parts of my first post. Wrong window, wrong machine, what i 
thought was f17 was f16. :( DS