One option I do want to draw your attention to in bodhi is "Require bugs", which "If checked, this will require that positive feedback be given on all associated bugs before the update can pass to stable. If your update has no associated bugs, this option has no effect.". We use this option (because it's default) - this means that the only reason the update advanced as quickly as it did was that someone asserted testing of the attached Windows bug. So the idea that Windows would somehow be more broken seems vanishingly unlikely to me.

Or they can be pushed faster, if the maintainer is certain and the feedback is great, but it should be a conscious decision, i.e. a manual push.

No, please do not inject more manual steps into our workflows. There are too many context switches already. If bodhi adds the ability to default to a minimum 24h in testing (for example), I would definitely consider enabling that. (I think it probably should be global, but now we're getting out of scope.)

In a few days, there will be some bug reports, if things break horribly.

And we get them, and fix them, as in this update :) Bugs will happen, no matter how much testing we throw at updates. That's just software.

Also, regarding karma feedback, it's a little misleading. It's true that overall we don't have enough testers providing karma (your examples, however, were from when Fedora 36 was pre-release, we have even fewer of them at that times).

I don't think so, because the same is true of released Fedoras. But the point is not to argue about specific updates: the point is that, as I think we both know, the amount of karma received is wildly variable and cannot be depended on. (You might recall the grub2 CVE update to post-release Fedora 35, where only you (thanks!) and one other person provided karma and it sat for the full 2 weeks.)

More generally, it seems to me that your issue is with the quality of feedback being provided by other testers on bodhi and the speed with which they provide it. The guidance for +1 is "Is the update generally functional?" - which I take to mean that the tester asserts that, according to their testing, they believe the package to function in an expected manner consistent with the release criteria. I am honestly not seeing a way it could mean anything else, nor can I vet the quality of testing based on the information they currently provide (and I don't think it's reasonable for me to do so).

No, not in the general case, but I will explain my thinking. Bodhi is also used for security updates, where, since Fedora has no embargoed build process, speed is also a concern. Generally bodhi updates sit for much longer: frankly, I think having a bug that people cared about caused this one to receive more attention during testing. For instance, see this previous Fedora 36 grub update that went stable due to time not karma, or this earlier grub2 update for Fedora 36 that went stable after 2 weeks and no karma at all, etc., etc.. The list goes on, but point is that it's normal to receive little if any karma, even on the bootloader.

As for "what if it breaks even more?"... well, that's tricky, isn't it? It's a risk on all changes, sure, but the reverse is also true. Especially in this case, where there's a high-profile bug we want fixed: which means that the longer we leave it unfixed, the longer ostree is broken and we can't chainload windows right. To be specific, adding to the profile of this bug is that it is believed to block a release criteria and was proposed as both Prioritized and Common. Obviously some people care a lot about getting this fixed quickly.

I hear your concerns about not wanting to play fast and loose with critpath packages. So far, I'm not aware of problems that have stemmed from the standard +3/2 weeks policy, though if that does start causing issues we can of course revisit. Given most of my updates are going to time already, I don't see the value in raising to 10-15 as you suggest: this seems like it would guarantee they all go to time.

pjones spoke to that in

f35, f36, and rawhide eventually all need the same build, so test with the one above, and I'll work with rel-eng on tagging when it's okay to do so.

Since this update is now stable, I imagine it will shortly be okay to do so if it's not already.


Boots my SB vm.

BZ#1922565 EFI HTTP boot fails if the HTTP headers are lower case
BZ#1999499 [F36FTBFS]: gnulib fails to build from source in Fedora Rawhide
BZ#2045453 gnulib: FTBFS in Fedora rawhide/f36

Please drop the grub2 bug from your non-grub2 update.

BZ#2045456 grub2: FTBFS in Fedora rawhide/f36

This update has been unpushed.

I created both at once - neither should be security as far as I know, so I think probably some bits got messed up somewhere. Thanks for checking!

Installed IPA server. Kerberos manipulation appears to be working correctly.

Sure, but there's no point doing that until FEDORA-EPEL-2019-b9d90e26c9 is stable, so you're going to have to wait.

Can you link to docs on how to do this correctly, or file actual bugs? The epel7+epel8 code doesn't work on epel6.


Worked for me on s390x server, thanks.

BZ#1741280 RFE: mosh: epel8 build request

Also please note that RHEL does not provide ABI (or even API) compat for libkadm5. We only provide compatability for krb5-libs.

Hi, krb5 maintainer here. The rubygem-rkerberos dependency discussion happened on

Please respond either here or in the bug, not both.

As I mentioned there, there is a separate ticket for KCM failures - because gssproxy is not responsible for KCM bugs.

Also -1ing the bug in question is just incorrect as I understand it, since the issue indicated is fixed by the patch (unless I applied it wrong, at which point please say so).

You... reviewed this patch upstream. You can either fix sssd now, or when the next ding-libs release happens, but waiting is just being a stick in the mud. Let's keep working together, please.