Fedora 23 Final blocker status #1

Adam Williamson adamwill at fedoraproject.org
Tue Oct 20 00:03:06 UTC 2015


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




More information about the devel mailing list