I would say this is probably more a releng issue. @jnsamyak Do you know what could be problem here?

I would say this is probably more a releng issue.

I never really know which is which. :(

Usually those that are related to building packages and working with them are releng issues. Infra issues are more oriented to stuck services or problems with VMs. But there is definitely an overlay between those.

Odd. I would have thought bodhi would have untagged it from overrides at the same time it went stable. ;(

In any case you should be able to tag them again into f43-updates-candidate and expire them and then untag them from f43-updates-candidate if they are still tagged.

Would you like me to do that? or can you?

Done.

However, does this mean there is some problem in the Bodhi config?

I'm not sure if this is something related to mass branching (as it happened right as that was starting) or some bodhi bug. ;(

@mattia thoughts?

I don't think Bodhi did ever remove the override tag from a build pushed into stable. The override tag was always removed only at override expiration time.

Also, for releases other than Rawhide, when a build is pushed to stable doesn't mean it is immediately available in buildroot - it only is after a successful compose. So I think it is right to not remove the override tag at the same time the stable tag is applied.

when a build is pushed to stable doesn't mean it is immediately available in buildroot - it only is after a successful compose

That's not correct. When a build is pushed to stable, it is available in the buildroot after the next repogen task.

when a build is pushed to stable doesn't mean it is immediately available in buildroot - it only is after a successful compose

That's not correct. When a build is pushed to stable, it is available in the buildroot after the next repogen task.

Oh, I thought that was true only for Rawhide. Anyway, I think there's not much difference in expiring the BRO when the build goes stable or wait for expiration time, but I think we can add to the list of tags removed in the processing task, if it seems better for you.

I think at the very least, Bodhi should let me expire my override without the need for manual tagging.

But I also think that it used to expire overrides when updates were pushed to stable. However, I have not done that in a long time.

https://bodhi.fedoraproject.org/updates/FEDORA-2025-3e2823604e is an update that goes stable on f41.

I submitted https://bodhi.fedoraproject.org/overrides/gerbera-2.6.0-3.fc41 to see what happens.

It expired automatically when the update went stable.

It expired automatically when the update went stable.

Sorry, I lost track of this discussion.
Yes, the bodhi composer task expires buildroot overrides related to the push. Automatic updates take a different path and there's no check about active buildroot overrides.

It should usually be not possible to submit a buildroot override for releases where automatic updates are active, but just because those updates should hit stable really soon. Perhaps if the update is gated, the user can submit the build as BRO... which is wrong, IMO.
I think it would be much better to disallow submitting BROs for releases with automatic updates and gating active, rather than fixing the expiration thing. @adamwill your thoughts?

I needed the buildroot overrides to be able to finish some work because bodhi updates occasionally get stuck for no apparent reason for a very long time. Please do not disable this feature.

So, a side tag wouldn't be a option for you? ie, make side tag, tag in the 'override' builds that are still waiting to go stable and build. Then wait until they go stable, untag from the overrides and submit the side tag?

This would also avoid the case of buildA is stuck in gating/bodhi, you make a override for it, build buildB and it goes stable, a compose happens and buildB is broken because it needs buildA

It would be more work though. :(

This would also avoid the case of buildA is stuck in gating/bodhi, you make a override for it, build buildB and it goes stable, a compose happens and buildB is broken because it needs buildA

The builds were not stuck on gating, but on signing.

It would be more work though. :(

Indeed :(

So perhaps for releases bodhi doesn't compose, it should just always expire any buildroot overrides for the builds? (just as it does for ones it does compose).

That was my expectation when I opened this issue, yes.

So, proibibly we should file that upstream?

https://github.com/fedora-infra/bodhi/issues/5937 is perhaps a similar case?

I added a link to this from there.