Hi folks! Time for a blocker status mail - well, past time, but I
hadn't found time to do one till now.
Status is that Go/No-Go is on Thursday: we really need an RC1 by
tomorrow in order to have sufficient testing time. Action summary:
Blocker reviewers
-----------------
Review:
* https://bugzilla.redhat.com/show_bug.cgi?id=1273102
*
https://bugzilla.redhat.com/show_bug.cgi?id=1273167
QA
--
Test proposed fixes:
* https://bugzilla.redhat.com/show_bug.cgi?id=1262600 (kickstart
change, must spin live image to test)
* https://bugzilla.redhat.com/show_bug.cgi?id=1261569 (updates.img for
testing against TC9)
Developers (inc. releng)
------------------------
Fix:
* https://bugzilla.redhat.com/show_bug.cgi?id=1263677 (wwoods, dnf-plugin-system-upgrade)
*
https://bugzilla.redhat.com/show_bug.cgi?id=1268802 (releng, fedora-repos /
fedora-release?)
*
https://bugzilla.redhat.com/show_bug.cgi?id=1271061 (plautrba, setroubleshoot)
Possibly fix (proposed blockers):
*
https://bugzilla.redhat.com/show_bug.cgi?id=1273102 (nmavrogi et al., gnutls)
*
https://bugzilla.redhat.com/show_bug.cgi?id=1273167 (lrintel, NetworkManager)
Here's the blow-by-blow on proposed and approved blockers:
Accepted
--------
1.
https://bugzilla.redhat.com/show_bug.cgi?id=1261569 - anaconda
"old kernel boots by default after upgrade"
We have a fix for this that's had a bit of testing, but could do
with more. To test, install TC9 with the updates.img and then update
the kernel, and check the new kernel is listed in 'grub2-editenv list'
output (and that it's the default choice on reboot).
2.
https://bugzilla.redhat.com/show_bug.cgi?id=1263677 - dnf-plugin-system-upgrade
"it's very easy to end up with a partially-upgraded system"
This is kind of a catch-all bug for the behaviour changes requested
to DNF and dnf-plugin-system-upgrade by FESCo. wwoods is working on
this one (after being out sick for a few days), we're expected a new
build of dnf-plugin-system-upgrade soon. I believe this can be
considered a 'special blocker' - i.e. it does not block the f23 image
compose, instead it must be pushed as an F21 and F22 update before
F23 release day.
3.
https://bugzilla.redhat.com/show_bug.cgi?id=1268802 - fedora-repos
"updates-testing is still enabled for Fedora 23"
This is just a request for the fedora-repos build that disables
updates-testing. We usually do this without a blocker bug, and
there's nothing difficult about it, releng will be doing it when
we're nearly ready for RC1.
4.
https://bugzilla.redhat.com/show_bug.cgi?id=1271061 - setroubleshoot
"[abrt] setroubleshoot-server: g_callable_info_free_closure(): python3.4 killed by
SIGSEGV"
This is a fairly newly-prioritized one, the SELinux alert browser
GUI is not really working right since its python3 port. The devs
are looking into it but we don't have a solid cause yet. Needs
dev work.
5.
https://bugzilla.redhat.com/show_bug.cgi?id=1262600 - spin-kickstarts
"Plasma live session notifies for available updates"
This is just as described in the summary. KDE team has just come up
with a possible patch and I'll be testing it shortly.
Proposed
--------
1.
https://bugzilla.redhat.com/show_bug.cgi?id=1273102 - gnutls
"Gnutls Servers (eg: cockpit) fail fallback with Google Chrome 46"
This is a bad behaviour in TLS init in gnutls which unfortunately
breaks access to the Cockpit UI on Server installs from recent
Chrome/Chromium builds. It seems like we're fairly clear on the
cause of this now and we have to make a call on how much of a
blocker it is; it would be great if devs could work on a fix in case
it is decided to be a blocker.
2.
https://bugzilla.redhat.com/show_bug.cgi?id=1273167 - NetworkManager
"ipv4.ignore-auto-dns=yes isn't honored"
The potential blocker issue here is that it seems you can't override
the DNS server used in anaconda by just passing a single parameter
as you should be able to, it seems you have to pass a whole static
config to dracut to avoid the DHCP-provided name server being the
default. This is a pain if you need to use a different DNS server for
registering with a FreeIPA / AD domain. sgallagh and I are reasonably
familiar with this scenario and our tentative take is that in most
production cases the DHCP-provided DNS server should support realm
discovery so it probably doesn't need to be a blocker, but we do want
to confirm that domain registration works in that case, and other
thoughts would be welcome. It would certainly be good if NM devs could
look at the problem here too.
Thanks everyone! It's looking pretty tight to get the release signed
off this week, but we'll do our best.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net