Hi,
On 01/29/2017 05:23 PM, Björn 'besser82' Esser wrote:
Allrighty… Looks like the override for libglvnd somehow got untagged… Just re-tagged in f25-build… Should be fixed now.
Well, that is a fix, but the real problem is that either the new libglvnd enabled
mesa should not be in updates-stable and thus not in the buildroot; or
both the new libglvnd enabled mesa and the new libglvnd should be in updates-stable.
What happened is I created an update in bodhi for libglvnd-0.2.999-7.gitdc16f8c.fc25
and mesa-13.0.3-3.fc25.
Then airlied did an unrelated bug-fix to mesa and created an update in bodhi for
mesa-13.0.3-4.fc25. This update did not obsolete my previous update, did not
inherit it bugs and did not inherit the libglvnd package which was only in my
update.
When I noticed things both updates were in perpetual locked state, when they
were finally unlocked airlied's update got auto-pushed to stable because of
karma (I had auto-karma disabled on mine), so now we have a mesa depending on
the latest libglvnd in updates-stable, without the latest libglvnd.
When I tried to also push my update to stable, I could not as bodhi complained
there was a newer mesa already in stable, so I had to remove mesa from my
update (why does it detect conflicts like this on push and not when someone
creates a conflicting update?), loosing all karma??? and now it is pending for
testing.
Frankly I blame this whole mess on bodhi, it should not allow creating
updates which partly obsolete other updates, there likely is a good reason
the partly obsoleted update bundled multiple packages in one update; or
it should allow it and then simply add all non obsoleted packages from
the obsoleted update to the new update and obsolete the old one.
I've had trouble with bodhi not doing proper obsoleting more often
lately, as well as having trouble with updates which involve obsoleting
getting in a perpetual locked state. Again frankly I've the feeling that
bodhi has regressed and that the old bodhi was more stable. We really need
to do better here, both with obsoleting and with the locked state thing.
Why does the admin side of bodhi not run a check to see everything is
unlocked again once the push is complete ? That should at least catch the
lock issue ?
For the 2 updates in question see:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e
https://bodhi.fedoraproject.org/updates/FEDORA-2017-9c9c0899f9
Regards,
Hans
Am 29.01.2017 um 17:19 schrieb Björn 'besser82' Esser:
Hi there!
The Fedora 25 buildroot on Koji is b0rk3n… :(
DEBUG util.py:435: Error: nothing provides libGL.so.1()(64bit) needed by muffin-devel-3.2.1-1.fc25.x86_64.
DEBUG util.py:435: nothing provides libEGL.so.1()(64bit) needed by clutter-1.26.0-1.fc25.x86_64.
DEBUG util.py:435: nothing provides libGL.so.1()(64bit) needed by cairo-gobject-1.14.8-1.fc25.x86_64.
DEBUG util.py:435: nothing provides libGL.so.1()(64bit) needed by cairo-1.14.8-1.fc25.x86_64.
DEBUG util.py:435: nothing provides libGL.so.1()(64bit) needed by cairo-gobject-1.14.8-1.fc25.x86_64.
DEBUG util.py:435: nothing provides libGL.so.1()(64bit) needed by cairo-1.14.8-1.fc25.x86_64.
DEBUG util.py:435: nothing provides libGL.so.1()(64bit) needed by cairo-1.14.8-1.fc25.x86_64.
DEBUG util.py:435: nothing provides libglvnd-glx(x86-64) needed by mesa-libGL-13.0.3-4.fc25.x86_64
Can the one who broke fix it, please?
Cheers
Björn
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
