16:01:14 <adamw> #startmeeting F25-blocker-review 16:01:14 <zodbot> Meeting started Mon Oct 24 16:01:14 2016 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:14 <zodbot> The meeting name has been set to 'f25-blocker-review' 16:01:14 <adamw> #meetingname F25-blocker-review 16:01:14 <adamw> #topic Roll Call 16:01:14 <zodbot> The meeting name has been set to 'f25-blocker-review' 16:01:25 <adamw> ahoyhoy folks, who's around for some SUPER EXCITING blocker review?(*) 16:01:30 <jkurik> .hello jkurik 16:01:31 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com> 16:01:37 <adamw> (*) excitement not guaranteed, flakes enlarged to show texture 16:01:50 * tenk is here 16:01:55 * satellit listening 16:02:07 <adamw> (*) this is not legal advice, prices may go down as well as up 16:02:09 <elliot007> I'm new but I'd like to stay here 16:02:14 <adamw> hi elliot! welcome 16:02:27 <adamw> (*) professional driver, closed course 16:02:46 * coremodule is here. 16:03:25 <adamw> (*) Acts of God excluded. see local dealer for details 16:05:04 <adamw> #chair jkurik coremodule 16:05:04 <zodbot> Current chairs: adamw coremodule jkurik 16:05:12 <adamw> #topic Introduction 16:05:12 <adamw> Why are we here? 16:05:12 <adamw> #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:05:12 <adamw> #info We'll be following the process outlined at: 16:05:13 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:05:14 <adamw> #info The bugs up for review today are available at: 16:05:16 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current 16:05:17 <adamw> #info The criteria for release blocking bugs can be found at: 16:05:19 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria 16:05:21 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria 16:05:23 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria 16:06:01 <adamw> who wants to be the secretary? 16:06:08 <adamw> comes with bonus extra fun! 16:06:10 <coremodule> I'll do it! 16:06:13 <coremodule> I like fun! 16:07:36 <adamw> woohoo fun 16:07:40 <adamw> #info coremodule will secretarialize 16:09:47 <adamw> alrighty 16:10:01 <adamw> we have: 16:10:01 <adamw> #info 2 Proposed Blockers 16:10:01 <adamw> #info 10 Accepted Blockers 16:10:05 <adamw> #info 3 Proposed Freeze Exceptions 16:10:05 <adamw> #info 3 Accepted Freeze Exceptions 16:10:18 <adamw> so let's get rolling with the proposed blockers! 16:10:24 <adamw> #topic (1384482) Screenshots and screencasts don't work on Wayland with multiple monitors (regression) 16:10:24 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1384482 16:10:24 <adamw> #info Proposed Blocker, mutter, VERIFIED 16:10:45 <adamw> so on the one hand this is a tricky call, on the other hand we really don't need to waste much time on it as a fix was backported and checked already 16:10:46 <adamw> we' 16:10:50 <adamw> we're just waiting for it to go stable 16:11:05 <adamw> so i'm gonna propose we don't waste time debating it and just 'punt' on the basis it'll get resolved soon anyhow 16:11:24 <adamw> oh, in fact, the update has gone stable already 16:11:30 <adamw> so we can close the bug and move on with life! awesome. 16:11:40 <jkurik> ack :) 16:11:48 <coremodule> Hah, ack! 16:12:01 <adamw> #agreed update has been pushed stable, we can close the bug and move on 16:12:11 <adamw> #topic (1380253) Netflix with Firefox DRM Plugin SELinux Policy 16:12:11 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1380253 16:12:11 <adamw> #info Proposed Blocker, selinux-policy, NEW 16:13:17 <cmurf> I had intended to test this with enforcing=0 before now, so if you want to skip and come back to this I'll test if you want to be abslutely certain it's an selinux problem. 16:13:42 <adamw> well, this is the only other blocker, so... 16:13:43 <cmurf> dwalsh seems to grok that it is 16:13:45 <adamw> er, proposed blocker 16:14:36 <adamw> we don't really need to know whether it's an selinux or not to debate its blockeriness i don't think 16:14:59 <adamw> kind of an interesting case, my instinct is that it's not quite 'basic functionality', but...it's fairly close i guess 16:15:33 <cmurf> Yes it's a subjective call whether DRM video playback is basic functionality. 16:16:04 <adamw> in *general* i'd like us to avoid pushing the 'basic functionality' wording too far 16:16:10 <adamw> because it could get awful subjective 16:16:33 <adamw> as written it was really meant to be about 'does this app just feel utterly broken to any reasonable user' 16:16:48 <adamw> like, maybe it technically doesn't crash but shows a blank grey screen 16:16:56 <adamw> or maybe it can't actually render HTML at all 16:16:58 <adamw> that kinda bug 16:17:19 <cmurf> Conversely it's filed against Fedora 24 and is still a problem. 16:17:53 <cmurf> But there is a work around - install Chrome 16:19:08 <jkurik> I am in doubth here. Watching video is IMO what every desktop user does, on the other hand adamw is right, we should be carefoul what basic functionality means 16:19:34 <adamw> i don't think i've ever used this feature, but i'm happy believing i'm in a minority... 16:19:54 * adamw still watches cable tv, and would like you to get off his lawn now 16:19:59 <cmurf> it's relatively recent I think 16:20:25 <adamw> so my instinct here is -1, but i'd be ok with being outvoted 16:20:26 <cmurf> previously the DRM was provided by flash 16:20:40 <adamw> i'd definitely be +1 FE 16:20:44 <dowdle> Considering it takes a bit of user work anyway to get working (two config changes and in two add-on plugins), how could this be considered basic functionality? 16:21:30 <cmurf> you get a button to enable DRM and once the plugins are downloaded (automatically) it just works 16:21:36 <cmurf> except selinux blocks the installation of the plugins 16:21:56 <cmurf> so the user sees one click wall 16:22:29 <jkurik> cmurf: if we need to download an extra plugin, then it is not default installation 16:22:51 <tenk> +1 16:22:52 <jkurik> si, I am -1 to block on this 16:23:06 <cmurf> jkurik: the downloading of the plugin is behind the scene, it comes along with clicking the "enable drm" button 16:23:47 <cmurf> I'm -1 blocker, but +1 FE - mainly to avoid encroachment on basic functionality, and also because there is a valid work around which is to install chrome 16:24:38 <cmurf> aren't we about to have chrome visible by default in Gnome Software? 16:24:44 <adamw> yeah, seems like it. 16:24:58 * adamw is really looking forward to the FSF finding out about that 16:25:17 <tenk> what is the difference by one click to install a package and one click to install a plugin 16:25:22 <tenk> for me it's customization 16:25:59 <cmurf> well technically anything being downloaded including javascript would be a customization from that point of view 16:26:03 <adamw> proposed #agreed 1380253 - RejectedBlocker AcceptedFreezeException (Final) - we agreed this doesn't really meet the definition of 'basic functionality', but it's obviously something many people will run into and it would be good to fix it if at all possible 16:26:16 <jkurik> ack 16:26:22 <cmurf> ack 16:26:24 <coremodule> ack 16:26:27 <tenk> ack 16:27:05 <adamw> #agreed 1380253 - RejectedBlocker AcceptedFreezeException (Final) - we agreed this doesn't really meet the definition of 'basic functionality', but it's obviously something many people will run into and it would be good to fix it if at all possible 16:27:11 <adamw> aaand that's all the proposed blockers 16:27:18 <cmurf> the bug may be in the category of mattdm's priority bug fixes idea 16:27:34 <adamw> so since that didn't take long, and we're getting closer to freeze, shall we do the proposed FEs? 16:27:38 <adamw> cmurf: yeah, probably would be 16:27:43 <cmurf> sure why not? 16:27:52 <jkurik> cmurf: yeah, that probably on me to finish the process 16:28:45 <adamw> #info moving to proposed FEs 16:28:52 <adamw> #topic (1382820) Xfce is missing some NetworkManager's libs 16:28:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1382820 16:28:53 <adamw> #info Proposed Freeze Exceptions, LiveCD - Xfce, NEW 16:30:32 <cmurf> +1FE 16:30:54 <adamw> sure, seems like this could be done pretty quickly if needed, but I'm OK with an FE for it in case nirik doesn't get to it before freeze 16:30:55 <adamw> +1 16:30:56 <jkurik> +1 FE 16:31:00 <coremodule> +1 FE 16:31:16 <adamw> technically it maybe doesn't need an FE since it'd be a kickstarts or comps change, but hey. 16:31:36 <adamw> proposed #agreed 1382820 - AcceptedFreezeException (Final) - we'd be fine with a tested change like this for Xfce after freeze. 16:31:58 <jkurik> ack 16:32:15 <coremodule> ack 16:32:42 <tenk> ack 16:32:50 <adamw> #agreed 1382820 - AcceptedFreezeException (Final) - we'd be fine with a tested change like this for Xfce after freeze. 16:33:24 <adamw> #topic (1188774) [anaconda] white screen on external monitor attached to a Lenovo ThinkPad T400 when docked and lid closed 16:33:24 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1188774 16:33:24 <adamw> #info Proposed Freeze Exceptions, metacity, NEW 16:35:36 <jkurik> hmm.. this is quite ancient bug 16:35:40 <adamw> yeah 16:35:47 <adamw> i think i'd want to see an actual patch before going FE on it 16:36:15 <jkurik> the same here 16:36:26 <cmurf> ack 16:36:37 <coremodule> Conditional FE? If we fix it, great, otherwise, release like we have since whenever it was first seen? 16:37:52 <adamw> coremodule: that's, um, already what an FE is =) 16:38:11 <adamw> but for something like this we kinda want a better idea of how disruptive the fix will be before deciding whether it makes sense to grant it an exception 16:38:49 <adamw> proposed #agreed 1188774 - punt (delay decision) - we don't think it makes sense to make a decision on this without a better idea of what any potential fix would look like and how disruptive it would be 16:39:03 <coremodule> Yeah, you're right. 16:39:34 <jkurik> ack 16:39:54 <coremodule> ack 16:40:15 <tenk> ack 16:41:48 <adamw> #agreed 1188774 - punt (delay decision) - we don't think it makes sense to make a decision on this without a better idea of what any potential fix would look like and how disruptive it would be 16:41:56 <adamw> #topic (1332266) systemd-logind does not verify if system has resume device defined when checking if can.hibernate or can.hybridsleep 16:41:56 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1332266 16:41:56 <adamw> #info Proposed Freeze Exceptions, systemd, NEW#topic (1332266) systemd-logind does not verify if system has resume device defined when checking if can.hibernate or can.hybridsleep 16:41:56 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1332266 16:41:57 <adamw> #info Proposed Freeze Exceptions, systemd, NEW 16:42:04 <adamw> wat 16:42:15 <adamw> $undo 16:42:17 <adamw> #undo 16:42:17 <zodbot> Removing item from minutes: INFO by adamw at 16:41:57 : Proposed Freeze Exceptions, systemd, NEW 16:42:20 <adamw> #undo 16:42:20 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x3c410890> 16:42:29 <adamw> #undo 16:42:29 <zodbot> Removing item from minutes: INFO by adamw at 16:41:56 : Proposed Freeze Exceptions, systemd, NEW#topic (1332266) systemd-logind does not verify if system has resume device defined when checking if can.hibernate or can.hybridsleep 16:42:34 <adamw> #info Proposed Freeze Exceptions, systemd, NEW 16:42:39 <adamw> there, i think that's right 16:42:50 <adamw> clearly the coffee IV is not strong enough today 16:43:23 <cmurf> this would be another one for the priority fixes pile 16:43:59 <cmurf> we've got to get more serious about reliable suspend to ram in particular, but also at least not making things bad when it's suspend to disk 16:46:55 <adamw> welp, if it's the same as F24 and we decided it was FE for F24, i'm fine with the same for F25. 16:47:06 <cmurf> yes +1FE 16:47:34 <coremodule> +! FE 16:47:40 <jkurik> +1FE, however I am wondering whether this should not be blocking as we might lose data 16:48:38 <adamw> we argued it long and hard last time... 16:48:50 <jkurik> ok then :) 16:49:05 <adamw> i'm not super keen on re-litigating it since nothing's changed about the bug or the criteria, but hey 16:51:55 <adamw> proposed #agreed 1332266 - AcceptedFreezeException (Final) - following the F24 decision, as neither the bug nor the relevant criteria have changed, we accept this as an FE 16:52:07 <cmurf> ack 16:52:07 <jkurik> ack 16:52:27 <coremodule> ack 16:52:33 <adamw> #agreed 1332266 - AcceptedFreezeException (Final) - following the F24 decision, as neither the bug nor the relevant criteria have changed, we accept this as an FE 16:52:52 <adamw> ok, we have one more satellit proposed 16:53:18 <adamw> #topic (1363915) soas f25 liveuser no longer logs in in live 16:53:25 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1363915 16:53:34 <adamw> #info Proposed Freeze Exceptions, sugar, ON_QA 16:53:54 <adamw> clear +1 for me 16:54:06 <cmurf> yes +1 otherwise they have nothing to ship 16:54:36 <coremodule> +1 16:56:36 <jkurik> +1 16:56:45 <adamw> proposed #agreed 1363915 - AcceptedFreezeException (Final) - this is a major issue in a non-blocking live image, so a clear +1 16:56:55 <adamw> proposed #agreed 1363915 - AcceptedFreezeException (Final) - this is a major issue in a non-blocking live image, so a clear freeze exception 16:57:02 <coremodule> ack 16:57:04 <jkurik> ack 16:57:06 <tenk> ack 16:58:44 <tenk> i will do some test tomorrow on other non blocking live image (x86_64/i386) to see if it's only on soas 16:59:16 <adamw> #agreed 1363915 - AcceptedFreezeException (Final) - this is a major issue in a non-blocking live image, so a clear freeze exception 16:59:26 <adamw> tenk: they all use different login managers, so it probably is. 17:01:08 <adamw> ok, that's all the proposed FEs 17:01:57 <adamw> looking at the accepted blockers, there's at least one we should revisit 17:02:07 <adamw> #info moving on to selected accepted blockers 17:02:14 <adamw> #topic (1383890) blivet.errors.DeviceError: ('cannot replace active format', 'sdc1') 17:02:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1383890 17:02:14 <adamw> #info Accepted Blocker, anaconda, NEW 17:02:37 <adamw> so we've had more testing on this since it was accepted and it turns out to be more conditional than we thought, and also sbueno says (as anaconda team leader) she doesn't think it should be a blocker 17:03:04 <adamw> as we said we were open to anaconda team's opinion on this being a blocker, i think i'm ok with changing to -1 17:03:50 <cmurf> It's an unsupported use case, that's the bottom line. 17:04:31 <cmurf> Wiping the target in advance for lives; or using netinstall is a work around. 17:04:43 <jkurik> I am fine not to block on this 17:05:00 <adamw> yup 17:05:01 <adamw> so that's -3 17:05:07 <coremodule> Same, based on Anaconda team's input. -1. 17:05:42 <adamw> proposed #agreed 1383890 - RejectedBlocker (Final) - with anaconda team's input that this isn't really a supported scenario and the fact that it's more conditional than we thought and there are many possible workarounds, we now consider this not to be a blocker 17:05:59 <cmurf> ack 17:06:04 <tenk> ack 17:06:08 <coremodule> ack 17:06:17 <satellit> ack 17:06:37 <adamw> #agreed 1383890 - RejectedBlocker (Final) - with anaconda team's input that this isn't really a supported scenario and the fact that it's more conditional than we thought and there are many possible workarounds, we now consider this not to be a blocker 17:06:55 <jkurik> ack 17:07:08 <cmurf> ack 17:07:28 <satellit> knoen bug ? I see this if I try to reinstall with liveusb to usb HD with same install on it 17:07:37 * satellit known* 17:08:28 <adamw> ok, another one that looks like it may need revisiting 17:08:34 <adamw> #topic (1375504) VM screen is often black after boot in gnome-boxes 17:08:34 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1375504 17:08:35 <adamw> #info Accepted Blocker, gnome-boxes, NEW 17:09:21 * cmurf is not sure whether this is getting attention 17:10:06 <adamw> well, per the final comment, it probably shouldn't be a blocker any more 17:10:17 <adamw> i'm not super familiar with the bug, but following the tracks, that's what it looks like 17:10:46 <cmurf> ahh i see 17:11:15 <cmurf> it has been a while though 17:12:02 * adamw testing it 17:12:08 <coremodule> Me too... 17:12:11 * jkurik has no clear opinion on this bug 17:12:52 <adamw> wow, i am actually amazed that this works, but it does 17:13:07 <coremodule> The flickering, or the resizing? 17:13:10 <adamw> so apparently boxes configures the VM display to be whatever size your boxes window viewport is 17:13:29 <adamw> so i now have a VM whose display is 1080x1873...and it works. 17:13:34 <adamw> no flickering or blackness 17:13:39 <cmurf> cool 17:13:50 <coremodule> I'm getting flickering, like the second bug. 17:14:01 <adamw> coremodule: what qemu version is your host system running? 17:14:10 <coremodule> The one kparal linked to in 1375504. 17:14:13 <coremodule> Lemme check... 17:14:38 <adamw> the flickering is supposed to be fixed as of qemu-2.7.0-6.fc25 17:14:53 <coremodule> Ah, okay. I haven't got the latest then. 17:15:29 <adamw> okay, so that adds up 17:15:32 <adamw> i'm just seeing if the black screen thing happens if i boot an f24 guest... 17:16:24 <adamw> hmm, nope, that works too. 17:16:38 <adamw> so, i feel pretty -1y on this now. 17:18:06 <cmurf> just close it as fixed? 17:18:09 <coremodule> Sure, I can get behind that. The behavior reported is no more. -1. 17:18:22 <jkurik> if it works then -1 and close the bug 17:18:27 <adamw> i don't think we can claim this bug is fixed for sure 17:18:40 <adamw> but i'm happy enough that i'm not seeing it in the most likely boxes scenarios 17:19:08 <cmurf> ok 17:19:12 <adamw> proposed #agreed 1375504 - RejectedBlocker (Final) - we're not sure if this bug is actually fixed, but as per #c8, it does not appear to be affecting typical OOTB Boxes use any more 17:19:31 <jkurik> at least it is not reproducible, so -1 to block 17:19:35 <jkurik> ack 17:20:15 <coremodule> ack 17:20:42 <cmurf> ack 17:21:07 <adamw> #agreed 1375504 - RejectedBlocker (Final) - we're not sure if this bug is actually fixed, but as per #c8, it does not appear to be affecting typical OOTB Boxes use any more 17:22:20 <adamw> so there's a couple of other blockers that need attention, but if it's ok by everyone i can look after that - i'll write a blocker status mail this week and ping the relevant folks 17:22:35 <adamw> anyone specifically want to discuss any of the other accepted blockers? 17:22:54 <cmurf> pass 17:23:22 <coremodule> Nothing here. 17:24:21 <jkurik> no 17:24:23 <adamw> allllrighty then 17:24:25 <adamw> #topic Open floor 17:24:52 <adamw> so i know you're all sick of it by now, but here is my hourly reminder that we need to make sure we complete the Final validation tests to find any remaining blockers :) 17:25:00 <adamw> if you're at a loose end, please do help run a few of those 17:26:03 <adamw> anyone got any other f25-y, blocker-y business? 17:27:36 * jkurik wants to have 0 blockers on the Go/No-Go meeting :) 17:28:22 <adamw> so do we all :) 17:30:45 <adamw> alright, thanks for coming everyone! 17:30:57 <jkurik> adamw: thanks for chairing 17:31:05 <adamw> #endmeeting