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