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