On Sun, 29 Jan 2017 18:12:59 +0100 Hans de Goede <hdegoede@xxxxxxxxxx> 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. :( > 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. > > 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
Attachment:
pgplmLXmENVhg.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
