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