16:00:03 <kparal> #startmeeting F27-blocker-review
16:00:03 <zodbot> Meeting started Mon Oct  2 16:00:03 2017 UTC.  The chair is kparal. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:03 <zodbot> The meeting name has been set to 'f27-blocker-review'
16:00:03 <kparal> #meetingname F27-blocker-review
16:00:03 <kparal> #topic Roll Call
16:00:03 <zodbot> The meeting name has been set to 'f27-blocker-review'
16:00:19 <kparal> so, who do we have here for a blocker meeting?
16:00:48 <kparal> kalev: sgallagh: nirik: lbrabec: ping
16:00:50 * lbrabec is here
16:00:56 <kparal> pwhalen: ping
16:00:56 <zodbot> kparal: Ping with data, please: https://fedoraproject.org/wiki/No_naked_pings
16:01:21 <kparal> ok, ok, ping "are you available for the meeting"? :)
16:01:32 <pwhalen> kparal, sorry on another, will join after
16:01:37 <kparal> ok, thanks
16:01:45 * kparal also pokes sumantrom[m]
16:01:54 * kparal tries to remember the usual attendees
16:02:33 <kparal> lbrabec: do you know how to secretarialize?
16:02:38 <lbrabec> no
16:03:08 <kparal> ok, I guess I'll do it
16:03:15 <kparal> if we have some people in the first place
16:03:25 <kparal> pschindl will be late, about 30 minutes I think
16:05:03 <kparal> tflink: we seem to be low on attendance, do you have time to join us?
16:05:14 <jforbes> I am here
16:05:21 <kparal> great
16:05:23 * mboddu is kinda here
16:05:51 * mboddu is busy with release bits
16:05:52 <tflink> yeah
16:06:15 <kparal> ok, let's start, I hope others will join later
16:06:28 <kparal> bear with me, I don't usually lead
16:06:28 <mattdm> i'm here
16:06:37 <d0minicpg> present
16:06:39 <kparal> #chair lbrabec tflink
16:06:39 <zodbot> Current chairs: kparal lbrabec tflink
16:06:50 <kparal> #topic Introduction
16:06:50 <kparal> Why are we here?
16:06:51 <kparal> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:06:51 <kparal> #info We'll be following the process outlined at:
16:06:51 <kparal> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:52 <kparal> #info The bugs up for review today are available at:
16:06:54 <kparal> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:56 <kparal> #info The criteria for release blocking bugs can be found at:
16:06:58 <kparal> #link https://fedoraproject.org/wiki/Fedora_27_Alpha_Release_Criteria
16:07:02 <kparal> #link https://fedoraproject.org/wiki/Fedora_27_Beta_Release_Criteria
16:07:04 <kparal> #link https://fedoraproject.org/wiki/Fedora_27_Final_Release_Criteria
16:07:13 <kparal> #info 9 Proposed Blockers
16:07:14 <kparal> #info 6 Accepted Blockers
16:07:14 <kparal> #info 0 Accepted 0-day Blockers
16:07:14 <kparal> #info 0 Accepted Previous Release Blockers
16:07:14 <kparal> #info 3 Proposed Freeze Exceptions
16:07:16 <kparal> #info 0 Accepted Freeze Exceptions
16:07:29 <kparal> let's start with the kernel one since jforbes is here
16:07:37 <kparal> #topic (1491320) heavy screen flicker with latest kernels in qxl+spice VM
16:07:37 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1491320
16:07:37 <kparal> #info Proposed Blocker, kernel, NEW
16:08:09 <kparal> so, in a nutshell, our VMs are now horribly broken with workstation by default
16:08:15 <kparal> screen unbearably flickers
16:08:35 <kparal> it's a combination of qxl+wayland+new kernel
16:08:49 <kparal> jforbes: what are the chances of having this fixed in kernel before F27 Final?
16:09:00 <jforbes> So we are in a pretty tough spot with this. Essentially it can't be backed out without reverting a large chunk of DRM.  Upstream is pretty clear that wayland gets no benefit from QXL and should not use it
16:09:01 <kparal> do you have any guess whether it's remotely possible?
16:09:11 <jforbes> kparal: this will likely not be fixed in kernel ever
16:09:49 <kparal> do you have any idea whether host qxl can be autodetected from inside the vm (and disable wayland, for example)?
16:10:04 <kparal> I was looking for crobinso but he's not online atm
16:10:06 <jforbes> It should be able to, I know nvidia reverted to X
16:10:33 <kparal> ok, so this could be one possible fix. not sure how difficult
16:10:49 <kparal> another is to default to virtio gpu driver in virt-manager and boxes
16:10:57 <kparal> again, I'm not sure whether it has any drawbacks
16:11:11 <mclasen> why not use the right driver ?
16:11:19 <kparal> mclasen: what do you mean?
16:11:25 <kparal> mclasen: and welcome :)
16:11:29 <jforbes> So the drawback there, is guests not using wayland will not have the best possible acceleration
16:11:30 <mclasen> what you just said, use the virtio gpu driver
16:11:47 <jforbes> mclasen: that is the right driver
16:12:03 <mclasen> yes
16:12:21 <kparal> so we would be decreasing performance for xorg sessions
16:12:22 <jforbes> https://bugzilla.kernel.org/show_bug.cgi?id=196777#c11
16:13:13 <ignatenkobrain> .hello2
16:13:14 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <ignatenko@redhat.com>
16:13:31 <kparal> mclasen: it's a solution. still, it would be good if system could autodetect a problematic setup and fall back to X11. since most people will not read commonbugs
16:13:41 <kparal> and their old VMs will exhibit the flicker
16:14:07 <kparal> mclasen: also, do you have any idea if switching to virtio can be done quickly in boxes?
16:14:19 <kparal> or is that a larger development effort?
16:14:31 <jforbes> kparal: old vms will not exhibit a flicker with virtio-vga, they just won't be as accelerated as they are with qxl
16:15:11 <kparal> by "old VMs" I mean those VMs created with qxl (the default driver) before we switch the default to virtio
16:15:28 <kparal> so "old vms" will have qxl, "new vms" will have virtio
16:15:32 <kparal> if I'm making sense
16:15:40 <kparal> or maybe misunderstanding something
16:15:44 <jforbes> right, that makes sense
16:15:51 <mattdm> (makes sense; I was thinking the same thing)
16:16:01 <kparal> so even if we switch the default, many many people will still see this problem
16:16:06 <jforbes> I don't see any controls in boxes for changing the hardware config at all
16:16:06 <kparal> and won't know how to fix it
16:16:27 <kparal> jforbes: yes, that's why I asked mclasen. I can't easily test whether it works or not
16:16:54 <jforbes> There is another issue here, outside of what we do with boxes in Fedora, what about people running Fedora guests on other hosts
16:17:07 <kparal> right, good remark
16:17:15 * mclasen not feeling constructive today, goes away
16:17:34 <kparal> also, F27 Beta seems to be broken in virtualbox, but I'm not sure if it's related or not - a black screen, reportedly
16:18:01 <jforbes> That would not be related, virtualbox uses it's own drivers
16:18:22 <kparal> mclasen: mhmm, I'd prefer you to stay...
16:19:40 <kparal> so, if gnome could detect qxl and fall back to x11, that would solve all issues. changing the default in virt-manager/boxes would make it possible to use wayland even in vm. a combination of both would work the best for fedora and other distros
16:20:03 <kparal> I'm not trying to find the best solution here, just figure out whether it's doable
16:20:22 <kparal> because I believe this is a blocker, but if we can't fix it in time, we won't have much choice here
16:20:50 <kparal> either way, I'd be +1 blocker at the moment. and the relevant devs will tell us if that's not possible to do in this timeframe
16:21:06 <kparal> wdyt?
16:21:42 <pwhalen> sounds reasonable, +1
16:22:32 <sumantrom[m]> +1
16:22:48 <jforbes> I will certainly try to push back on upstream for a better solution in kernel, I just don't see it as likely. I cannot comment on whether the other solutions are feasible as I have no idea what that code looks like
16:23:02 <tflink> +1
16:23:46 <lbrabec> +1
16:23:58 <kparal> proposed #agreed - #1491320 - AcceptedBlocker (Final) - This violates "The release must be able host virtual guest instances of the same release" criterion. Affected parties, please find a solution here.
16:24:35 <kparal> ack/nack/patch?
16:24:45 <tflink> ack
16:24:47 <lbrabec> ack
16:24:53 <sumantrom[m]> Ack
16:25:44 <kparal> #agreed - #1491320 - AcceptedBlocker (Final) - This violates "The release must be able host virtual guest instances of the same release" criterion. Affected parties, please find a solution here.
16:25:56 <kparal> #topic (1484916) Can not get destinations from CUPS server
16:25:56 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1484916
16:25:56 <kparal> #info Proposed Blocker, cups, MODIFIED
16:26:48 <kparal> so, printer dialog is empty in gnome
16:26:58 <kparal> setting up a fake default printer would be a fine workaround for beta, I feel
16:27:01 <kparal> but not for Final
16:28:13 * pschindl is here
16:28:17 * sumantrom[m] concurs with kparal
16:28:35 <kparal> a question is whether this is "default application functionality", but I think we can consider this as one
16:28:44 <kparal> pschindl: welcome :)
16:29:30 <sumantrom[m]> pschindl: Hii
16:30:08 <kparal> so this is +1 blocker for me
16:30:12 <kparal> other votes?
16:30:17 <tflink> +1
16:30:41 <pwhalen> +1
16:30:55 <kparal> we can also say that the control center app is not showing printers as it should
16:30:55 <tflink> sorry, not very details. agree that a fake printer isn't ideal for final
16:31:04 <kparal> and then it matches the criterion better
16:31:19 <tflink> do we have any idea how likely a fix is for final?
16:31:43 <kparal> it's already submitted
16:31:52 <tflink> oh
16:31:53 <kparal> according to that bodhi link
16:32:16 <zdohnal> tflink: bugzilla is in modified state, patch was backported from upstream and I tested it with reporter steps - it works with patch
16:32:48 <kparal> proposed #agreed - #1484916 - AcceptedBlocker (Final) - This violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test" for control center app and showing printers.
16:33:10 <pschindl> ack
16:33:12 <pwhalen> ack
16:33:12 <lbrabec> ack
16:33:28 <tflink> zdohnal: yeah, I'm just slow today, apparently :-/
16:33:29 <tflink> ack
16:33:36 <mboddu> ack
16:33:39 <kparal> #agreed - #1484916 - AcceptedBlocker (Final) - This violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test" for control center app and showing printers.
16:33:50 <kparal> #topic (1490832) dnf system-upgrade: dnf.exceptions.MarkingError: no package matched
16:33:50 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1490832
16:33:51 <kparal> #info Proposed Blocker, dnf-plugins-extras, MODIFIED
16:33:57 <sumantrom[m]> +1
16:35:02 <tflink> +1 from me as well
16:35:08 <tflink> +1 blocker, rather
16:35:09 <kparal> this happens only if you use --enablerepo during dnf system-upgrade download
16:35:17 <kparal> a workaround is simple, enable the repo permanently
16:35:22 <kparal> still, annoying
16:35:28 <kparal> and unclear from the error
16:36:21 <kparal> I'm not completely decided here, but probably more of a blocker
16:36:34 <kparal> enabling repo on cmdline is quite frequent, especially with updates-testing
16:36:41 <kparal> might be even documented somewhere
16:36:41 <mboddu> +1 blocker
16:36:58 <pschindl> +1
16:37:03 <lbrabec> +1 blocker
16:37:34 <kparal> proposed #agreed - #1490832 - AcceptedBlocker (Final) - This violates "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed." when --enablrepo is used.
16:37:48 <kparal> proposed #agreed - #1490832 - AcceptedBlocker (Final) - This violates "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed." when --enablerepo is used.
16:38:10 <lbrabec> ack
16:38:11 <mboddu> ack
16:38:13 <tflink> ack
16:38:30 <kparal> #agreed - #1490832 - AcceptedBlocker (Final) - This violates "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed." when --enablerepo is used.
16:38:43 <kparal> #topic (1492036) system-upgrade fails to connect to online mirrors during upgrade when caches are missing
16:38:43 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1492036
16:38:43 <kparal> #info Proposed Blocker, dnf-plugins-extras, MODIFIED
16:39:15 <kparal> this one happens if F26(!!) caches are missing, e.g. when doing dnf clean all before starting upgrade
16:39:33 <kparal> but I think we also saw it happen in some other cases, maybe if caches were outdated
16:39:43 <kparal> but I'm not clear on that one and it's harder to reproduce
16:40:16 <kparal> also, jmracek didn't reproduce it, but I could do it consistently
16:40:22 <kparal> in a fresh VM
16:40:53 <kparal> so I'm not so sure here, maybe punt a week before we gather more details (or the fix is verified and goes stable)
16:41:18 <tflink> wfm
16:42:01 <pwhalen> +1 punt
16:42:29 <kparal> proposed #agreed - #1492036 - Punt (delay decision) - We'll wait until this is confirmed by multiple parties or more ways to trigger this are found.
16:42:46 <lbrabec> ack
16:42:58 <tflink> ack
16:42:59 <pwhalen> ack
16:43:17 <kparal> #agreed - #1492036 - Punt (delay decision) - We'll wait until this is confirmed by multiple parties or more ways to trigger this are found.
16:43:29 <kparal> #topic (1495635) systemd times out when waiting to unlock disks, falling to dracut shell
16:43:29 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1495635
16:43:29 <kparal> #info Proposed Blocker, dracut, POST
16:43:56 <kparal> we've had this before and I think it was a blocker, but I didn't check
16:44:17 <kparal> anyway, we shouldn't release like this I believe
16:44:38 <pwhalen> +1, this is annoying
16:44:43 <lbrabec> I hated this when it happened before
16:44:44 <lbrabec> +1
16:44:46 <kparal> people complained that upgrade failed, because after they returned they saw a rescue shell
16:45:04 <pschindl> +1
16:45:09 <nb> +1
16:45:34 * nb experienced this issue and was confused until i just rebooted and tried again
16:45:35 <tflink> at least +1 FE
16:45:50 <tflink> but I'm not -1 blocker, either
16:46:11 * nb thinks blocker
16:46:26 <kparal> proposed #agreed - #1495635 - AcceptedBlocker (Final) - This violates boot-related criteria when the system is encrypted and is not unlocked quickly enough.
16:46:33 <nb> ack
16:46:36 <lbrabec> ack
16:46:41 <pschindl> ack
16:46:42 <tflink> ack
16:47:01 <kparal> #agreed - #1495635 - AcceptedBlocker (Final) - This violates boot-related criteria when the system is encrypted and is not unlocked quickly enough.
16:47:12 <kparal> #topic (1494061) gnome-software doesn't show F25->F27 upgrade even though it should
16:47:12 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1494061
16:47:12 <kparal> #info Proposed Blocker, gnome-software, NEW
16:47:28 <kparal> so, this would be AcceptedPreviousRelease, if accepted
16:47:57 <kparal> it quite clearly violates the cited criterion, I think
16:48:25 <kparal> please note that nobody confirmed this, I might've done something wrong. but in that case it can always be lifted
16:48:42 <kparal> we'll action somebody else from QA to test this independently
16:48:58 <tflink> eh, I think that's it's arguably not a blocker but that involves splitting some hairs
16:49:15 <kparal> tflink: please argue :)
16:49:29 <tflink> the criterion doesn't say that it's must be possible to directly upgrade from n-2
16:49:44 <tflink> you _can_ upgrade - you just need to go through 26 first
16:49:58 <kparal> " a direct upgrade "
16:50:20 <kparal> I was proposing that criterion, I know why I included the *direct* word :)
16:50:36 <kparal> that was the time when we officially started supporting n+2 upgrades
16:50:46 <tflink> fair enough. does the cli work?
16:50:48 <kparal> before that, only n+1 was supported and tested
16:50:51 <kparal> tflink: yes
16:51:17 * tflink doesn't know why he's arguing this one, doesn't have a problem with blocker
16:51:29 <kparal> that's fine, clarification
16:51:48 <kparal> "This criterion applies to the recommended upgrade mechanisms only."
16:51:57 <pschindl> +1
16:52:07 <kparal> both approaches should work, since both are recommended
16:52:15 <pwhalen> +1
16:52:23 <tflink> +1
16:52:25 <lbrabec> +1
16:53:10 <kparal> proposed #agreed - #1494061 - AcceptedBlocker (Final) - This violates "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed." for gnome-software on F25.
16:53:15 <tflink> ack
16:53:18 <lbrabec> ack
16:53:18 <mboddu> ack
16:53:23 <pschindl> ack
16:53:34 <kparal> #agreed - #1494061 - AcceptedBlocker (Final) - This violates "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed." for gnome-software on F25.
16:53:35 <pwhalen> ack
16:53:46 <kparal> #topic (1479932) gi.overrides.BlockDev.LVMError: Process reported exit code 5:   Volume group "VolGroup00" not found
16:53:46 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1479932
16:53:47 <kparal> #info Proposed Blocker, libblockdev, NEW
16:54:23 * tflink is thinking punt and wait for reproduction on this one
16:54:54 <kparal> yes, proper reproduction steps are needed and at least someone else hitting this too
16:55:20 <lbrabec> +1 punk
16:55:23 <lbrabec> ah
16:55:26 <lbrabec> +1 punt
16:55:49 <kparal> proposed #agreed - #1479932 - Punt (delay decision) - We'll wait until this has detailed reproduction steps and somebody else manages to successfully reproduce it.
16:55:50 <pschindl> +1 punt
16:55:53 <tflink> ack
16:55:55 <pwhalen> ack
16:55:56 <pschindl> ack
16:55:57 <mboddu> ack
16:55:59 <lbrabec> ack
16:56:18 <kparal> #agreed - #1479932 - Punt (delay decision) - We'll wait until this has detailed reproduction steps and somebody else manages to successfully reproduce it.
16:56:28 <kparal> #topic (1482692) gi.overrides.BlockDev.LVMError: Failed to call the 'Activate' method on the '/com/redhat/lvmdbus1/Lv/0' object: GDBus.Error:org.freedesktop.DBus.Python.dbus.exceptions.DBusException: ('com.redhat.lvmdbus1.Lv', 'Exit code 5, stderr =   Volume group ...
16:56:29 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1482692
16:56:29 <kparal> #info Proposed Blocker, libblockdev, NEW
16:56:58 <kparal> this is likely the same bug or similar
16:57:07 <kparal> the same approach here I think
16:57:16 <tflink> yeah
16:57:18 <lbrabec> yep
16:57:27 <pschindl> +1 punr
16:57:29 <pschindl> punt :)
16:57:33 <kparal> proposed #agreed - #1482692 - Punt (delay decision) - We'll wait until this has detailed reproduction steps and somebody else manages to successfully reproduce it.
16:57:35 <lbrabec> ack
16:57:41 <tflink> also looks like the anaconda bug which is the bane of my existence when re-installing the taskotron-client-hosts
16:57:42 <pschindl> ack
16:57:50 <tflink> smells kinda like, rather
16:57:57 <tflink> ack
16:58:09 <kparal> #agreed - #1482692 - Punt (delay decision) - We'll wait until this has detailed reproduction steps and somebody else manages to successfully reproduce it.
16:58:16 <kparal> #topic (1475565) initramfs not generated at default location if /boot/<machine-id> exists
16:58:17 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1475565
16:58:17 <kparal> #info Proposed Blocker, systemd, NEW
16:58:52 <kparal> so, I did a very poor job proposing this
16:59:02 <kparal> I was bit in a hurry
16:59:18 <kparal> I reproduced this easily with clean F27 installation, but not with F26->F27 upgrade
16:59:36 <kparal> there's /boot/some-hash, and dracut -f creates initramfs in there, instead of updating the existing one
16:59:48 <kparal> however, new kernels created initramfs just fine for me
17:00:04 <kparal> which didn't sound the case for person in comment 12
17:00:11 <kparal> so, my experience differs here
17:00:48 <kparal> still, this sounds very bad for any tool that regenerates initramfs (or for users who do that manually, etc after updating crypttab)
17:00:58 <kparal> and I gues some security implications could be there as well
17:01:15 <kparal> e.g. updating initramfs with plymouth security fix or something
17:01:43 <kparal> this doesn't directly violate anything, but could be considered a security problem
17:02:07 <kparal> or, if comment 12 is correct and I was just lucky, this would violate a lot of stuff, breaking boot :)
17:02:11 <kparal> so, take your pick
17:02:42 <kparal> jforbes: still around?
17:02:47 <tflink> another punt?
17:03:22 <kparal> we could give it more testing, yes
17:04:18 <tflink> as a heads up, I need to go AFK in about 30 minutes
17:04:19 <kparal> or ask relevant people outside of this meeting
17:04:27 <pschindl> I'm also +1 punt. But it sounds like a bad bug
17:04:28 <tflink> or both :)
17:04:57 <tflink> pschindl: in my mind, it depends on the details that got kparal to not see it vs. comment 12
17:05:14 <tflink> either way, worth more testing/digging
17:05:44 <pwhalen> +1 punt
17:06:00 <tflink> +1 punt for more testing and/or digging, to be more formal
17:06:09 <kparal> proposed #agreed - #1475565 - Punt (delay decision) - We need to perform more testing to estimate the user impact better.
17:06:55 <pschindl> ack
17:07:06 <tflink> ack
17:07:38 <lbrabec> ack
17:07:41 <kparal> #agreed - #1475565 - Punt (delay decision) - We need to perform more testing to estimate the user impact better.
17:07:55 <kparal> ok, those are proposed blocker
17:07:58 <kparal> blockers
17:08:23 <kparal> #info Proposed FEs
17:08:52 <kparal> I'll skip 1479932 and 1482692 since we already discussed them as blockers and punted
17:09:02 <kparal> a single one remains
17:09:04 <kparal> #topic (1497458) implantisomd5sum fails to implant on 32 bit x86
17:09:04 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1497458
17:09:05 <kparal> #info Proposed Freeze Exceptions, isomd5sum, NEW
17:09:39 <kparal> releasing i686 images without working md5sums sounds like a bad idea, so I'm +1 FE here
17:09:46 <jforbes> This has been pointed out to the i686 SIG
17:10:23 <tflink> +1 FE
17:10:28 <lbrabec> +1 fe
17:10:37 <pschindl> +1 FE
17:10:41 <mboddu> kparal: +1 FE but as jforbes said, we need to take it to i686 SIG and have a fix for it asap
17:11:00 <pwhalen> +1 fe
17:11:07 <kparal> proposed #agreed - #1497458 - AcceptedFreezeException (Final) - We prefer to release i686 images with working checksums, as long as the fix is not invasive and doesn't break anything else.
17:11:19 <tflink> ack
17:11:20 * mboddu dont want people to think we are dropping i686 support
17:11:23 <mboddu> ack
17:11:25 <lbrabec> ack
17:11:28 <pwhalen> ack
17:11:43 <kparal> #agreed - #1497458 - AcceptedFreezeException (Final) - We prefer to release i686 images with working checksums, as long as the fix is not invasive and doesn't break anything else.
17:12:11 <kparal> jforbes: do you have a minute to go back and discuss 1475565 ?
17:12:26 <pschindl> ack
17:12:36 <jforbes> Sure
17:12:50 <kparal> #topic (1475565) initramfs not generated at default location if /boot/<machine-id> exists
17:12:50 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1475565
17:12:50 <kparal> #info Proposed Blocker, systemd, NEW
17:13:14 <kparal> jforbes: what do you think about security implications of not updating initramfs when dracut -f is called?
17:13:26 <kparal> or any other implications you can think of?
17:14:13 <kparal> I want to hear your thoughts in case new kernel installs generate initramfs fine, but tools trying to update it don't work
17:14:28 <jforbes> Possible missing drivers and such are the biggest issue
17:15:09 <jforbes> I mean it isn't really a workable long term solution, there are many reasons to need to update the initramfs
17:15:59 <kparal> aren't all drivers already present when it's generated with the new kernel installed? how would failing to update initramfs miss some drivers?
17:16:33 <kparal> also, what are your thoughts on this being a blocker (considering this case as described)?
17:16:54 <jforbes> Third part modules could be an issue, drivers not part of the kernel proper than dkms builds
17:17:10 <kparal> oh, I see. nvidia trying to build its module and such?
17:17:13 <kparal> virtualbox, etc?
17:17:19 <jforbes> I would be +1 to blocker
17:17:45 <jforbes> We also see a lot of failures for whatever reason fixed by rebuilding initramfs
17:18:25 <kparal> ok, thanks for details. we'll revisit this bug on our next meeting, hopefully with more testing done
17:18:34 <jforbes> thanks
17:18:56 <kparal> that's it for proposed blockers and FEs
17:19:07 <kparal> I think it doesn't make much sense to go through accepted as this point
17:19:12 <kparal> so
17:19:14 <kparal> #topic Open floor
17:19:23 <kparal> anybody has a topic to raise?
17:20:10 <tflink> nothing from me
17:21:06 * kparal will keep this open for a few more minutes
17:25:43 <kparal> ok, thanks everyone for attending
17:25:48 <kparal> #endmeeting