Comments

1763 Comments
karma

It's the same problem as in F36 update. Let's give it 3 negative karma and unpush it.

karma

I can confirm the issue above.

karma

This fixes a bluetooth reconnection problem from https://bugzilla.redhat.com/show_bug.cgi?id=2100761 . Thank you, Hans!

clinfo and clpeak works on Thinkpad P1 gen3 with UHD Graphics [0x9bc4]

no visible regressions on my Workstation

Czech manpages are displayed fine under the Czech locale

karma

I can start my container

Let me clarify, I'm not saying grub updates should sit here for 2 weeks. I'm just saying they should sit here at least for some reasonable minimum amount of time (my personal choice would be 2-3 days at least). 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. Windows boot was broken because there was automatic push enabled, and the first negative comment came just 1 hour too late. By disabling automatic push or raising the limits high enough, you can be sure it's not triggered in just a few hours and you can use your own judgement whether it's the right time to push it now or wait a day longer.

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). But that doesn't mean they don't get tested. We have hundreds, maybe thousands, maybe more people running with updates-testing enabled. They just don't submit karma. But if something important breaks for them, you can be sure some of them will file a bug. So while it seems like the Bodhi feedback is quiet, there's a lot of value in waiting some time, because there will certainly be some feedback, if the update is broken. But not immediately, people are distributed all over the globe, and they don't update every day. In a few days, there will be some bug reports, if things break horribly.

So, the previous update broke Windows boot for a large portion of our users because it spent mere 13 hours in testing, and this new update spent just 7 hours in testing and is again being pushed stable for everyone. This is just great. What if it breaks it even more?

@rharwood, would you please consider disabling "stable by karma" option for such critical packages as grub? Or at least increase the number to something like 10-15 instead of the default 3? We can't afford to push packages like grub so quickly, this is a recipe for a disaster. Thank you.

searching seems to work fine

karma

I use it every day, no issues

karma

no issues in daily Workstation usage

karma

no issues in daily Workstation usage

I can connect to my SMB shares in Nautilus

karma

no issues with Workstation apps theming

videos in totem play fine

I see:

systemd[1655]: selinux: avc:  denied  { status } for auid=1000 uid=1000 gid=1000 path="/proc/self/mountinfo" cmdline="/usr/bin/gnome-shell" function="mac_selinux_filter" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=service permissive=0

repeated in journal over and over again. Quite interestingly, it's not shown in "selinux alert browser".

karma

I can start my container

karma

no issues in regular usage