In the wake of the BZ 1924808 discussion in Thursday's Go/No-Go
meeting, I am proposing an addition to the Basic Release
Criteria. This would go into Post-Install Requirements -> Expected
installed system boot behavior -> First boot utilities (appended after
the existing sentence):
> If a utility for creating user accounts and other configuration is configured to launch, it must be visible within 10 seconds of the first boot reaching the launch point.
Why 10 seconds? Why not? That sort of feels like the maximum length of
time someone could reasonably be expected to wait. A shorter time
might be better.
I don't particularly love the wording here, but I wanted to make it
clear that it's not 10 seconds from power on, but 10 seconds from the
time the boot up reaches the state where we expect gnome-initial-setup
or its counterparts to appear.
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
I wonder if we couldn't add in some (re)testing of upgrades after a release
is 'go' but before it's actually released. We hit at least two issues I
am aware of with f34 due to multilib. ;(
pipewire.i686 is in the base x86_64 repo and users had/have it installed.
pipewire.i686 is pulled into the x86_64 base repo by mutter (mutter.i686
is there and requires pipewire.i686).
In any case it is not in the updates repo, so once an update of them
is pushed (which it has been), upgrades fail due to the missing
I have modified the updates pungi config to whitelist pipewire for
multilib and it's in f34-updates now.
There's still an issue with iptables.
basically the version in the base repo has a 'iptables' package.
The one in updates Obsoletes this for a iptables-compat, but yet it's
not doing things correctly as users are getting dnf errors.
Anyhow, I think it might be good to perhaps schedule some re-resting of
upgrades after the 0 day updates repo is populated to try and catch
these and fix them before release day.
We can't test this fully before there is an updates repo (I mean we kind
of can with updates-testing, but it's not the exact same repo).
I'm running kernel-5.11.17-200.fc33.x86_64 with my F33, and I
tried to upgrade from F33 tp F34. I performed all adviced steps
the last download step "sudo dnf system-upgrade download --releasever=34".
But nothing special happens when calling the last step "sudo dnf
The system is booted without any message into F33 again, and I dont
Anybody has an idea what to do for getting some important infos?
Fedora release 33 (Thirty Three)
Joachim Backes <joachim.backes(a)rhrk.uni-kl.de>
Hello all, last week I noticed and reported a bug I noticed with Fedora 34 KDE and fcitx. Basically having fcitx loaded causes LibreOffice Impress to segfault. I've seen this on two different machines now run the FL34 KDE Plasma betas, both were upgrades from FL33 where this setup worked fine.
I've also noticed that fcitx will no longer load on login even with fcitx.desktop placed in .config/autostart
Has anyone else noticed issues with fcitx on I'm thinking about switching over to ibus-mozc for Kana Kanji input needs and see if that fixes it.
Bug report here: