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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
