Hi,
On 01/29/2017 08:00 PM, Kevin Fenzi wrote:
On Sun, 29 Jan 2017 18:12:59 +0100
Hans de Goede <hdego...@redhat.com> wrote:
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.
Yeah, currently bodhi doesn't obsolete if the other update is locked or
if the other update has a different packageset.
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.
:(
Yeah, this is quite unfortunate :(
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.
I'll leave the above for bodhi developers to comment on.
This has always been a complicated area, but I agree we could do
better.
I've filed:
https://github.com/fedora-infra/bodhi/issues/1254
To track this.
Regaards,
Hans
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 ?
It does. The "lock issue" was just because we couldn't get a
f25-updates-testing push to complete due to rpm-ostree issues. So, IMHO
it was completely right to lock those until the push finished.
I guess of your suggestions it might indeed be best to reject a new
update when there's already one in existance that it cannot obsolete
(because it's locked or has a different packageset). I'm sure that will
annoy some people, but seems cleanest to me and then allows people to
discuss and modify the in-flight update or whatever.
kevin
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
