16:02:18 <adamw> #startmeeting F25-blocker-review
16:02:18 <zodbot> Meeting started Mon Oct 17 16:02:18 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:18 <zodbot> The meeting name has been set to 'f25-blocker-review'
16:02:20 <adamw> #meetingname F25-blocker-review
16:02:20 <zodbot> The meeting name has been set to 'f25-blocker-review'
16:02:22 <adamw> #topic Roll Call
16:02:42 * kparal is here
16:03:12 * coremodule is here.
16:03:15 * garretraziel is kinda here
16:03:32 * satellit afk but listening
16:03:53 * coremodule is also willing to act as secretary.
16:04:09 * pschindl is here
16:04:15 <adamw> garretraziel: kinda here?
16:04:28 <adamw> did you become a ghost? :)
16:04:38 <adamw> #chair coremodule kparal
16:04:38 <zodbot> Current chairs: adamw coremodule kparal
16:05:37 <garretraziel> I'm here, but I'm also preparing myself a dinner :-)
16:05:52 <adamw> i see
16:05:59 <adamw> hmm, we're all qa-y
16:06:18 <kparal> garretraziel: I'm always preparing a dinner during meetings, don't worry
16:06:22 <adamw> nirik: jkurik: mclasen: jforbes: ping
16:08:02 * cmurf aquiring supplies, but will be here
16:08:10 <mclasen> adamw ?
16:08:25 <adamw> mclasen: got time to help us with blocker review?
16:08:33 <mclasen> of course!
16:08:36 <adamw> thanks
16:08:50 <adamw> we're mostly qa folks so far so i was pinging non-qa people
16:09:04 <adamw> alrighty, boilerplate time...
16:09:04 <adamw> #topic Introduction
16:09:04 <adamw> Why are we here?
16:09:04 <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:09:06 <adamw> #info We'll be following the process outlined at:
16:09:06 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:09:08 <adamw> #info The bugs up for review today are available at:
16:09:10 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:09:12 <adamw> #info The criteria for release blocking bugs can be found at:
16:09:16 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria
16:09:18 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria
16:09:20 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria
16:09:22 <adamw> #info coremodule will secretarialize
16:09:47 <adamw> we have:
16:09:47 <adamw> #info 6 Proposed Blockers
16:09:47 <adamw> #info 9 Accepted Blockers
16:09:51 <adamw> #info 3 Proposed Freeze Exceptions
16:09:51 <adamw> #info 3 Accepted Freeze Exceptions
16:10:00 <adamw> starting with proposed blockers...
16:10:02 <adamw> #topic (1383890) blivet.errors.DeviceError: ('cannot replace active format', 'sdc1')
16:10:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1383890
16:10:02 <adamw> #info Proposed Blocker, anaconda, NEW
16:10:52 <adamw> so this seems to be installing to a usb stick with certain contents?
16:11:27 <coremodule> That's how it reads to me...
16:11:58 * adamw pings dlehman
16:12:01 <cmurf> yes
16:12:09 <cmurf> it has a previous f25 installation on the stick
16:12:13 <cmurf> if the stick is empty, it works
16:12:14 <adamw> on the one hand i kinda read this as +1 per the criteria, on the other hand i really hate that criterion :P
16:12:17 <cmurf> if the stick has f25 it crashes
16:12:20 <adamw> though the crash is bad
16:12:52 <adamw> the error message reads like it's automounting the stick's partitions or something...
16:12:55 <kparal> we probably should support usb-connected disks the same way we do sata-connected disks
16:13:11 <kparal> it can be frequent enough
16:13:45 <adamw> i'm not sure whether anaconda team considers it supported
16:14:11 <adamw> i guess my inclination here is +1 but i'm willing to listen if anaconda team says we're idiots and it shouldn't block
16:14:12 <cmurf> it could be the live environment is confusing things, e.g. usb automounting
16:14:25 <adamw> cmurf: that seems pretty plausible, have you tried it from a non-live installer?
16:14:31 <cmurf> i haven't
16:15:00 <adamw> satellit: around? was your reproducer of this from a live image too?
16:15:03 <kparal> it's probably automounting and starting LVM
16:15:43 * adamw brb
16:18:04 <cmurf> 1. make the crash +1 blocker 2. ask if usb sticks are supportable in live or netinstall or both 3. needinfo cmurf does the problem happen with netinstall?
16:20:34 <pschindl> I'm +1 here. If anaconda team will say that day don't want to support it then we can just put it to common bugs.
16:21:21 <cmurf> with sticks and sd media now being big and fast enough for this to be a valid use case, it'd be good to have it supported; just not sure if the live environment is thwarting it all
16:21:43 <coremodule> Agreed, +1 here.
16:21:45 <cmurf> plus it's vastly less fragile than l-i-t-d persistent sticks
16:22:00 <adamw> thinking about it, didn't anaconda devs say they removed some kind of initial storage reset stuff from anaconda this cycle?
16:22:13 <adamw> maybe that was unmounting usb sticks at the start of live installs...
16:23:20 <cmurf> no idea
16:23:33 <adamw> yeah, i can go with that plan
16:23:42 <cmurf> the no idea plan? :P
16:24:27 * cmurf wonders if there's a rancid lag going on
16:24:47 <adamw> proposed #agreed 1383890 - AcceptedBlocker (Final) - we're provisionally accepting this as it does pretty much meet the criteria, but we're open to anaconda team arguing that this should not be a blocker (they were not available at the meeting)
16:24:54 <adamw> cmurf: only in my brain, unfortunately
16:24:57 <garretraziel> ack
16:25:00 <coremodule> ack
16:25:01 <adamw> ^^^ that plan
16:26:42 <adamw> any more acks?
16:26:47 <adamw> or nacks or patches?
16:26:55 <cmurf> ack
16:26:56 <kparal> ack
16:27:44 <adamw> #agreed 1383890 - AcceptedBlocker (Final) - we're provisionally accepting this as it does pretty much meet the criteria, but we're open to anaconda team arguing that this should not be a blocker (they were not available at the meeting)
16:27:54 <adamw> #topic (1385684) Cannot install F25 from local hard disk using Fedora Workstation live ISO
16:27:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1385684
16:27:54 <adamw> #info Proposed Blocker, anaconda, NEW
16:28:21 <cmurf> so the gist here, as I understand it, without any logs attached...
16:28:46 <cmurf> the ISO file is on sda5 which is /home, and the user gets GRUB to find and boot that ISO
16:29:06 <cmurf> and then wants to install to sda6, without repartitioning; so just formatting sda6 as required
16:29:50 <adamw> i thought the 'install from an ISO file' feature was meant for the Server DVD-type image, not any Workstation image
16:29:51 <kparal> well we never tested this approach, not sure it's officially supported
16:30:04 <adamw> but if it worked before...hrm
16:30:11 <adamw> really wish we had an anaconda folk here :/
16:30:13 <kparal> adamw: and even for that you boot from netinst/pxeboot and just point anaconda to an existing .iso
16:30:26 <adamw> yeah, i don't actually grok quite what the scenario is here
16:30:57 <adamw> ohh. he's actually configuring a grub menu entry to boot the ISO
16:31:01 <kparal> this seems to be basically a Live image, but booted from iso stored on disk directly
16:31:05 <adamw> then running the installer from the live environment...
16:31:06 <adamw> hrm.
16:31:38 * adamw reads criteria again
16:32:04 <adamw> Alpha "Supported media types" reads "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with at least one of the officially supported methods."
16:32:36 <cmurf> final does say using any available means though - how literal is that to be taken?
16:32:37 <adamw> and 'installer requirements' preamble reads "Except where otherwise specified, each of these requirements applies to all supported configurations described above." (which in context includes that 'supported media types' definition)
16:32:47 <adamw> cmurf: that's what the test case says, not what the criteria say.
16:32:53 <cmurf> oh i see
16:33:14 <cmurf> i would like this to work, but I don't think it's practical to block on this
16:33:27 <adamw> afaics we don't change the 'supported media types' definition or that preamble at beta or final
16:33:31 <adamw> so i'd argue this isn't covered, and be -1
16:33:42 <cmurf> yeah i'm leaning that way also
16:34:03 <adamw> i mean, definitely a bug, but by inclination and criteria it doesn't feel blocker to me.
16:34:05 <adamw> FE, maybe
16:34:07 <kparal> -1 here as well
16:34:18 <cmurf> here's an anecdotal gotcha though
16:34:38 <cmurf> macOS can do this
16:34:51 <pschindl> I'm -1 too. User can use other way for the installation (I think, that at least usb will be available).
16:35:02 <cmurf> the installer is an app, it explodes itself somehow that it can boot the system, then do an installation
16:35:24 <cmurf> so it'd be a neat use case to make pretty instead of say dnf system upgrade, to do clean installs
16:35:34 <cmurf> but i think someone needs to make it a feature and own it
16:35:43 <cmurf> prove it can work and be maintained, and then write up a test case
16:36:07 <cmurf> so i'm reluctantly -1 blocker
16:36:18 <kparal> if such a feature exists, we would add it specifically to criteria, I'd say
16:36:31 <adamw> anyone want to argue +1?
16:36:33 <garretraziel> I'm also -1
16:36:37 <cmurf> I think not having to write sticks is a +
16:36:59 <pschindl> cmurf: You can burn the dvd :)
16:37:00 <cmurf> download and just have some app configure a temp bootloader to boot the image file, and do a clean install
16:37:19 <cmurf> pschindl: i feel dirty at the thought of burning dvds :D
16:37:23 <garretraziel> cmurf: that would be awesome for clean reinstalls
16:38:02 <adamw> proposed 1385684 - RejectedBlocker (Final) - the criteria definition of 'supported media' (from Alpha) does not include direct booting the ISO from a hard disk, so we don't consider this scenario covered by the criteria
16:38:13 <pschindl> ack
16:38:16 <cmurf> ack
16:38:20 <garretraziel> ack
16:38:20 <kparal> ack
16:38:22 <coremodule> ack
16:38:37 <garretraziel> (but it's a shame it worked before and now it doesn't)
16:38:43 <adamw> #agreed 1385684 - RejectedBlocker (Final) - the criteria definition of 'supported media' (from Alpha) does not include direct booting the ISO from a hard disk, so we don't consider this scenario covered by the criteria
16:38:45 <adamw> sure
16:38:47 <cmurf> garretraziel: well if someone wants to work on it i'll help with the design and with trying to blow it up
16:38:59 <adamw> #topic (1376471) global menu can't be used for 15-30 seconds, startup notification stuck, missing item in alt+tab (on wayland)
16:38:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1376471
16:38:59 <adamw> #info Proposed Blocker, gnome-shell, NEW
16:39:43 <cmurf> egads
16:39:53 <adamw> mclasen: what's your take on this one?
16:39:55 <garretraziel> I think I saw this with some 3rd party apps even on Xserver, isn't this something about missing "app started up" signal?
16:42:26 <kparal> just imagine the poor reviews who want to try the global menu. what reviews they will write... /me shudders
16:42:36 <kparal> *reviewers
16:42:45 <cmurf> old bug though
16:43:00 <kparal> that depends. I've seen that in the past
16:43:15 <kparal> or rather I did see this sometimes with libreoffice, but with nothing else
16:43:24 <kparal> *haven't
16:43:25 <mclasen> there is a particular startup notification bug on wayland
16:43:54 <mclasen> I'll track down the right people to comment on it
16:44:22 <kparal> mclasen: would you be fine with releasing F25 without the fix?
16:45:00 <mclasen> not really, no
16:45:13 <kparal> ok
16:46:15 <kparal> I'm +1 here as well, in certain cases it's very inconvenient or confusing (like trying to run "change background" another time)
16:46:30 <cmurf> +1 blocker
16:46:38 <kparal> and of course you can't go into app preferences/create a new account in empathy/etc
16:46:48 <garretraziel> +1 blocker
16:47:30 <adamw> ok, i can go +1 too
16:48:34 <adamw> proposed #agreed 1376471 - AcceptedBlocker (Final) - this is considered to effectively violate "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" as it affects expected use of core Shell functions with standard apps
16:48:43 <cmurf> ack
16:48:46 <coremodule> ack
16:48:58 <kparal> ack
16:49:27 <garretraziel> ack
16:49:37 <adamw> #agreed 1376471 - AcceptedBlocker (Final) - this is considered to effectively violate "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" as it affects expected use of core Shell functions with standard apps
16:49:45 <adamw> #topic (1188774) [anaconda] white screen on external monitor attached to a Lenovo ThinkPad T400 when docked and lid closed
16:49:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1188774
16:49:45 <adamw> #info Proposed Blocker, metacity, NEW
16:49:49 <adamw> metacity?
16:50:19 <kparal> probably yes, because netinst
16:50:22 <adamw> ah. right.
16:50:40 <cmurf> oh i had my bugs confused, this is the old bug
16:50:44 <adamw> i'm almost sure we've discussed this or an identical bug before
16:51:53 <adamw> i'm kinda inclined to -1, it's a bug, but it didn't block the last four releases and i don't off the top of my head see a reason it should block this one
16:52:00 <adamw> it's obviously only a conditional violation of the cited criterion
16:52:07 <kparal> this is a can of worms, from my POV
16:52:42 <kparal> with certain connections, you can't even detected whether external monitor is on or off
16:52:49 <kparal> *detect
16:53:07 <adamw> that's kinda how i recall the discussion going before, yeah
16:53:11 <adamw> we had X maintainers around i think
16:53:17 <kparal> this might be very specific to the reporter's setup
16:54:43 <cmurf> i'm skeptical of supporting secondary displays for installation
16:55:01 <adamw> i guess the argument here is that X should've made it the *primary* display
16:55:07 <adamw> but like kparal says, that's a can of worms...
16:55:22 <adamw> i think the other argument we've had before is that anaconda should mirror by default
16:55:33 <kparal> I understand the person might not expect this and not realize to open up the laptop lid, but ...
16:55:48 <cmurf> ok rewrite: i'm skeptical of supporting displays there were ever at one time considered anything but the primary display
16:55:52 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=725219
16:55:53 <kparal> I don't really dare to block on these issues
16:56:02 <cmurf> s/there/that
16:56:27 <cmurf> that was two epochs ago?
16:57:27 <adamw> filed for F15
16:57:31 <adamw> so it's gettin' pretty smelly now :)
16:58:45 <adamw> but yeah, i don't really see a reason for it to suddenly become a blocker, so i'm -1
16:59:02 <kparal> -1
16:59:47 <pschindl> -1
17:01:29 <adamw> proposed #agreed 1188774 - RejectedBlocker (Final) - Fedora's behaviour in this case has not changed for many releases and this bug is only a very conditional violation of the criteria
17:01:33 <cmurf> ack
17:01:44 <garretraziel> ack
17:01:45 <coremodule> ack
17:01:57 <pschindl> ack
17:02:04 <adamw> #agreed 1188774 - RejectedBlocker (Final) - Fedora's behaviour in this case has not changed for many releases and this bug is only a very conditional violation of the criteria
17:02:12 <adamw> #topic (1384482) Screenshots and screencasts don't work on Wayland with multiple monitors (regression)
17:02:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1384482
17:02:12 <adamw> #info Proposed Blocker, mutter, NEW
17:02:46 <adamw> i'm kinda mehhhhh to blocking the release on this one...
17:03:27 <cmurf> yeah me too
17:03:30 <cmurf> use X
17:03:39 <kparal> I have to admit I haven't seen borked screenshot as Jiri uploaded
17:03:47 <cmurf> part of the bandaid being ripped off
17:03:49 <coremodule> I don't see this either...
17:03:50 <kparal> in my case always the left monitor was OK (in full) and the right monitor was missing
17:04:01 <adamw> kparal: yeah, that's how it is for me too
17:04:08 <adamw> might depend on the geometry i guess
17:04:09 <kparal> however, this prevents me from reporting dual screen issues
17:04:12 <kparal> most of them
17:04:23 <kparal> because for that, I need both monitors to be shown
17:04:24 <adamw> well, i mean, it doesn't *really*. worst case you can always go with 'take a photo'.
17:04:28 <cmurf> I haven't tried this on F25 wayland though, so it if happens there then it's definitely a regression which leads me to believe it's emminently fixable and can be done with an update
17:04:39 <kparal> "use X" doesn't help when those are wayland issues
17:04:53 <cmurf> use cell phone camera :S
17:04:58 <kparal> adamw: yes I could, but for minor glitches it's hard to capture them
17:05:21 <cmurf> well the powers that be can fix the bug whether it's a blocker or not
17:05:32 <kparal> the problem here is that it's not an app broken, all apps are broken. so we're releasing F25 with non-functional screenshot/cast with *any* app on multi-monitor setups
17:05:42 <kparal> I imagine a laptop with an external monitor is not that rare
17:05:51 <cmurf> i have just such a setup
17:06:01 <cmurf> and i do take screenshots often
17:06:45 <cmurf> who's the Workstation WG contact person here?
17:06:48 <cmurf> Do they want to block on this?
17:06:57 <adamw> well, mclasen's the guy on the spot :)
17:07:25 <kparal> I'm not 100% convinced it should be a blocker myself. but I wouldn't object
17:07:44 * mclasen looks up
17:07:55 <cmurf> I'm on U.S.S. Ship It
17:08:00 <mclasen> the screenshot thing ? I have people looking into it
17:08:01 <kparal> mclasen: https://bugzilla.redhat.com/show_bug.cgi?id=1384482
17:08:10 <mclasen> I'd like to get that fix in, if we can
17:08:14 <mclasen> but I don't have it yet
17:08:16 <kparal> mclasen: would you want to block on it?
17:08:24 <mclasen> probably not
17:08:33 <cmurf> freeze exception?
17:08:44 <mclasen> sounds right tome
17:08:55 <kparal> ok
17:09:05 <cmurf> -1 blocker, +1 freeze exception sine it sounds like a fix may come after freeze
17:09:07 <adamw> that's kinda where i am on this one
17:09:11 * kparal is known to be easily convinced
17:10:04 <kparal> -1/+1 works for me
17:10:14 <adamw> proposed #agreed 1384482 - RejectedBlocker (Final), AcceptedFreezeException (Final) - we don't consider this severe enough to constitute a violation of the cited criterion, but we do think it's significant enough to warrant taking a fix through freeze if we get to that point
17:10:16 <pschindl> -1/+1 too
17:10:25 <garretraziel> ack
17:10:27 <coremodule> ack
17:10:28 <kparal> do we have a secretary, btw?
17:10:40 <coremodule> Aye, tis me.
17:10:45 <kparal> coremodule++
17:10:54 <kparal> ack
17:11:08 <adamw> #agreed 1384482 - RejectedBlocker (Final), AcceptedFreezeException (Final) - we don't consider this severe enough to constitute a violation of the cited criterion, but we do think it's significant enough to warrant taking a fix through freeze if we get to that point
17:11:15 <adamw> #topic (1382001) Switching between users doesn't work and freezes the desktop
17:11:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1382001
17:11:15 <adamw> #info Proposed Blocker, sddm, NEW
17:11:40 <kparal> speaking of can of worms... KDE :o)
17:12:45 <kparal> so basically live user switching is broken, you have to log out first
17:13:00 <cmurf> do we have  acriterion?
17:13:09 <kparal> it's quoted
17:13:25 <cmurf> yeah but that's a bit  of a stretch
17:13:36 <kparal> that's what we used for gnome live user switching in the past
17:13:40 <cmurf> it's not wrong by any means but I bet dual user is rare
17:13:50 <cmurf> ahh
17:13:54 <adamw> so whenever user switch bugs come up, my position is that we don't block on it cos it's hard...the criteria that are explicitly about login/logout/shutdown actions intentionally don't include user switching
17:13:59 <kparal> my experience is opposite, most of my home setups have multiple users
17:14:10 <adamw> but i think we've gone different ways on different bugs before :/
17:14:10 <kparal> and we live switch pretty often
17:14:23 * adamw looks for KDE peep
17:14:24 <adamw> s
17:14:41 <cmurf> i'm not saying i don't want it to work, just whether we'd block on it - they can fix it anytime outside of freeze
17:15:01 <cmurf> have we really blocked on user switching for workstation before?
17:15:03 <kparal> I consider this very basic functionality. but I'm not sure KDE will be able to keep up here
17:15:20 <adamw> cmurf: i don't recall
17:15:23 <kparal> I'd vote +1 if it were GNOME
17:15:33 <adamw> sometimes i wish we had a handy All Previous Blockers search...
17:15:57 <kparal> in KDE the whole implementation was barebones in the past, you were shown a dialog teaching you to switching using Ctrl+Alt+Fn...
17:15:58 <cmurf> i'll vote +1 if KDE folks have any sense of whether we'd be blocking for a couple weeks or two months
17:16:01 <cmurf> or indefinitely
17:16:45 <cmurf> but if there's no resources to make sure we aren't blocking indefinitely, I don't see the point
17:17:24 <pschindl> The easiest fix would be to remove the switch user button from the menu.
17:17:30 * kparal searching for the GNOME bug
17:17:42 <cmurf> pschindl: yeah i'd support that
17:18:08 * adamw pinged rdieter and kevin_kofler but no reply yet
17:18:11 <cmurf> make it a blocker and they just remove the UI element to enable switching as the work around fix
17:18:30 <cmurf> hmmm
17:18:34 <cmurf> freezes the desktop
17:18:40 <cmurf> does that mean open applications lose their data?
17:18:49 <kparal> see https://bugzilla.redhat.com/show_bug.cgi?id=1184933
17:19:13 <kparal> accepted as beta blocker
17:19:20 <cmurf> if data loss is involved, and removing the user switching UI is a viable work around, I'd +1 blocker it
17:19:51 <kparal> data loss is potentially involved, since GUI freezes
17:20:18 <kparal> thus you can't access your open apps anymore
17:20:29 <adamw> so looking at the log of the meeting for 1184933, i made more or less the same argument but couldn't find enough references and lost. :P
17:20:46 <kparal> :)
17:20:51 <adamw> of course, when we were voting on that bug a fix was available
17:21:00 <adamw> and we're always less finicky about bugs where there's already a fix
17:21:14 <adamw> but still, i'll go with that as precedent and vote +1
17:21:54 <kparal> I'd also go with +1 provisionally, and if KDE folks they're not able to fix it in time, we'll need to reconsider this again
17:22:00 <kparal> *say
17:22:09 <cmurf> +1 kparal
17:22:31 <pschindl> +1 ^^^
17:22:36 <cmurf> I don't mind it just not working, as much as it causing data loss
17:23:18 <kparal> but if it's utterly broken, maybe they could simply just deactivate/remove the button
17:23:24 <cmurf> right
17:23:59 <adamw> proposed #agreed 1382001 - AcceptedBlocker (Final) - this is considered a violation of "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops" as 'switch user' is an offered mechanism, with 1184933 as precedent
17:24:10 <cmurf> ack
17:24:28 <pschindl> ack
17:24:53 <kparal> ack
17:25:02 <adamw> #agreed 1382001 - AcceptedBlocker (Final) - this is considered a violation of "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops" as 'switch user' is an offered mechanism, with 1184933 as precedent
17:25:14 <adamw> I went with the criterion we used for 1184933 rather than the one cited in the bug.
17:25:28 <cmurf> fair enough
17:25:31 <adamw> alright, so, that's supposedly the end of the proposed blockers, but - https://bugzilla.redhat.com/show_bug.cgi?id=1379098 should be on the list too
17:25:34 <adamw> and i can't see why it isn't
17:25:44 <kparal> coremodule: please add a note that we don't require the functionality to be in, so if they disable/remove it, it solves the problem. also if they don't want to do that but also can't fix it in time, they should let us know
17:25:46 <adamw> so now i'm worried and i'm gonna run a bugzilla search to see if we have any more lurking hidden proposed blockers...
17:26:06 <coremodule> kparal, I can do that!
17:26:32 <kparal> adamw: or wait 4 minutes
17:26:42 <kparal> muzak time!
17:27:22 <cmurf> oh god, the muzak torture test, build those calluses in your ears kparal
17:27:33 <adamw> ah, i bet it was because the bug was private
17:27:54 <adamw> so blockerbugs is probably in some messed-up state where it knows about the bug but couldn't get info from it and won't refresh it now it's public
17:28:17 <adamw> so i'll just do it manually, tum ti tum...
17:28:42 <adamw> #topic (1379098) [Regression] Gnome-shell crashes on switching back from tty ([abrt] gnome-shell: wl_resource_post_event(): gnome-shell killed by SIGSEGV)
17:28:50 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1379098
17:29:01 <adamw> #info Proposed Blocker, gnome-shell, NEW
17:29:06 <kparal> I can't reproduce this in a VM, and I'm not sure I want to test this right now on my laptop
17:29:19 <adamw> kparal: i can reproduce it all the time on my desktop.
17:29:45 * kparal tries it
17:29:53 <kparal> no crash
17:30:11 <kparal> adamw: do you have nouveau? I saw some reports earlier regarding nouveau
17:30:19 <adamw> yeah, i do
17:30:57 <kparal> now the question is whether OP has it as well
17:31:32 <kparal> adamw: or do you have a non-nvidia computer at hand where you could try this?
17:31:38 <kparal> with F25
17:33:07 <adamw> not offhand
17:33:40 <kparal> we can try tomorrow in the office with nvidia and radeon
17:33:45 <adamw> we can punt on this one for data
17:33:58 <adamw> if it's very hardware specific i'd be ok with -1, but it is pretty bad
17:35:06 <kparal> if you look at https://fedoraproject.org/wiki/Test_Day:2016-10-13_Wayland
17:35:19 <kparal> there are more people complaining about this with nvidia hw
17:35:28 <kparal> " Renault "
17:36:46 <kparal> I think it's likely a generic nouveau issue
17:36:47 <adamw> i'd probably argue for +1 if it affects *all* nvidia hardware
17:37:04 <cmurf> i'm not seeing this in the blocker list
17:37:09 <kparal> yeah, might make sense
17:37:59 * kparal is fine with punt or voting and assume all nvidia hw is affected
17:38:15 <kparal> my english today, oh my
17:40:02 <adamw> cmurf: see above discussion.
17:40:13 <adamw> kparal: understood that did i
17:41:46 <adamw> so are people feeling vote-y or punt-y?
17:42:01 <cmurf> uhhh
17:42:08 <cmurf> well it's another crash and possible data loss
17:42:21 <kparal> so far we have 3 confirmed cases, all with nvidia
17:42:28 <cmurf> hmmm that sucks
17:42:36 <kparal> and in my case (bare metal intel and VM) no crash
17:42:44 <kparal> you're all free to try as well
17:42:54 <kparal> just ctrl+alt+f3 and back
17:42:56 <cmurf> yeah i have radeon+i915, or i915 only
17:43:07 <cmurf> and this is a regression
17:43:09 <adamw> let's play wayland russian roulette!
17:43:17 <cmurf> wait it's a wayland only thing?
17:43:27 * kparal just tried it 6 times in a row
17:43:32 <kparal> no explosion
17:43:49 <cmurf> ok but if it does explode, it only explodes with wayland, not X
17:44:13 <adamw> cmurf: yeah, it's wayland.
17:44:18 <cmurf> -1 blocker
17:44:24 <kparal> oh wow I just got logged out
17:44:28 <cmurf> use X if you don't want it to crash
17:44:28 <kparal> gnome-shell crash
17:44:32 <kparal> so maybe I did reproduce this
17:44:46 * kparal running it through FAF
17:44:58 <kparal> the roulette was a good idea
17:45:12 <cmurf> i'm happy to reconsider if any workstation folks think we should block on it
17:45:36 <cmurf> but at the moment i consider this part of the air hitting the owie
17:46:30 * kparal generating the traceback
17:47:05 <adamw> cmurf: that line kind of has a limit, though
17:47:21 <cmurf> adamw: sure
17:47:23 <cmurf> it's a gotcha
17:47:28 <cmurf> and it's sort of bait and switch
17:47:28 <adamw> cmurf: there's a point at which it doesn't make any sense to have wayland as the default if we're telling huge swathes of people not to use it
17:47:45 <adamw> 'don't use it if you need to play triple-A games', okay
17:47:58 <adamw> 'don't use it if you have an NVIDIA card and you ever want to switch to a VT', hmm
17:48:02 <cmurf> haha
17:48:17 <cmurf> ok i'm at 0 blocker now
17:49:01 <kparal> so I apparently hit https://bugzilla.redhat.com/show_bug.cgi?id=1379440
17:49:12 <cmurf> if all or most ndvidia gpus are affected i get to +0.5 blocker
17:49:31 <kparal> which has a slightly different traceback
17:50:50 <kparal> in a VM I can't reproduce that
17:51:02 <adamw> kparal: what version of mutter do you have?
17:51:11 <kparal> mutter-3.22.1-2.fc25.x86_64
17:51:49 <adamw> hmm, so 3.22.0-2 was supposed to fix the one your crash turned up as a dupe of...
17:51:55 <adamw> can you check your actual backtrace manually?
17:52:02 <kparal> ok I can reliably reproduce this it seems
17:52:03 <adamw> maybe abrt's not right here
17:52:18 <kparal> it crashed again
17:53:25 <kparal> my backtrace is this one: https://retrace.fedoraproject.org/faf/reports/1365203/
17:53:34 <kparal> compared to: https://retrace.fedoraproject.org/faf/reports/1330357/
17:53:39 <kparal> not sure why those symbols are missing
17:54:18 <kparal> I'll get a backtrace of the second crash
17:54:33 <adamw> yeah, you know what to do
17:54:45 <adamw> so...let's do something :) +1? -1? punt?
17:54:47 <kparal> that's this one: https://retrace.fedoraproject.org/faf/reports/1363582/
17:54:49 <adamw> i think i'm +1 on this at this point
17:54:55 <kparal> and that seems like the one you all hit with nvidia
17:55:08 <kparal> so I'd say this is the same, just happens easier with nouveau
17:55:18 <adamw> i'm open to reconsidering if appropriate, but it feels +1y to me
17:55:22 <kparal> yeah, +1 for the moment
17:56:43 <coremodule> +1 here.
17:56:59 <adamw> mclasen: wdyt?
17:58:29 <kparal> adamw: my second crashed got duped with 1379098
17:58:30 <kparal> bingo
17:58:39 <kparal> *crash
17:58:57 <adamw> i guess it can crash in different cursor movement related functions or something...
17:59:48 <adamw> welp, we've got +3, so let's go with that for now.
18:00:27 <adamw> proposed #agreed 1379098 - AcceptedBlocker (Final) - this is accepted as a blocker as a violation of "All known bugs that can cause corruption of user data must be fixed or documented at Common F25 bugs", as proposed in comment #12
18:00:47 <kparal> ack
18:00:57 <coremodule> ack
18:01:43 <garretraziel> ack
18:02:29 <adamw> #agreed 1379098 - AcceptedBlocker (Final) - this is accepted as a blocker as a violation of "All known bugs that can cause corruption of user data must be fixed or documented at Common F25 bugs", as proposed in comment #12
18:02:50 <adamw> we might have to go into blockerbugs manually somehow and fix that one if it doesn't show up as an acceptedblocker either, i guess
18:03:21 <adamw> ok, so final freeze isn't till 11-01, so we don't really need to do proposed FEs yet
18:03:34 <adamw> anyone super keen to do those or run through accepted blockers, or shall we call it a day?
18:03:50 <cmurf> call it a day unless a brief overview is possible
18:03:51 * kparal is super keen to call it a day
18:04:17 <adamw> let's do that then
18:04:22 <adamw> #topic Open floor
18:04:29 <adamw> i'll check through the accepted blockers after the meeting
18:04:39 <adamw> any other vaguely blocker/release-related business?
18:06:11 <adamw> allllrighty then
18:06:13 * adamw sets fuse
18:07:12 <adamw> thanks for coming folks!
18:08:07 <coremodule> As always, thanks for hosting adamw!
18:08:14 <adamw> yoooouuuuu're welcome
18:08:24 <coremodule> And a bottle of rum
18:08:33 <kparal> thanks everyone
18:08:38 <adamw> #endmeeting