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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
