17:01:59 <adamw> #startmeeting F25-blocker-review
17:02:00 <zodbot> Meeting started Mon Nov  7 17:01:59 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:00 <zodbot> The meeting name has been set to 'f25-blocker-review'
17:02:00 <adamw> #meetingname F25-blocker-review
17:02:00 <adamw> #topic Roll Call
17:02:00 <zodbot> The meeting name has been set to 'f25-blocker-review'
17:02:10 <adamw> morning folks! who's around to review some blockers?
17:02:12 * kparal is here
17:02:13 <sgallagh> .hello sgallagh
17:02:14 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:02:16 * pschindl is here
17:02:18 <jkurik> .hello jkurik
17:02:19 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
17:02:39 * coremodule is here.
17:02:46 * satellit listening
17:03:00 * garretraziel is lurking around, preparing lunch
17:03:35 <jforbes> .hello jforbes
17:03:36 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
17:04:16 <adamw> morning morning
17:04:23 <adamw> .chair jkurik sgallagh
17:04:26 <zodbot> jkurik sgallagh is seated in a chair with a nice view of a placid lake, unsuspecting that another chair is about to be slammed into them.
17:04:34 <sgallagh> heh
17:05:39 <jkurik> zodbot is in a good mood today
17:05:47 <adamw> ....man, i think i need to go back to bed and redo this morning
17:05:51 <adamw> #chair jkurik sgallagh
17:05:51 <zodbot> Current chairs: adamw jkurik sgallagh
17:06:00 <adamw> let's try that again with the RIGHT cryptic sigil
17:06:23 <Southern_Gentlem> adamw, tomrrow will be worse
17:07:00 <adamw> maybe next time i'll try /chair and see what happens
17:08:14 <adamw> #topic Introduction
17:08:14 <adamw> Why are we here?
17:08:14 <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.
17:08:14 <adamw> #info We'll be following the process outlined at:
17:08:16 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:08:16 <adamw> #info The bugs up for review today are available at:
17:08:18 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
17:08:20 <adamw> #info The criteria for release blocking bugs can be found at:
17:08:21 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria
17:08:23 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria
17:08:27 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria
17:08:29 <adamw> we have:
17:08:31 <adamw> #info 7 Proposed Blockers
17:08:33 <adamw> #info 3 Accepted Blockers
17:08:35 <adamw> #info 10 Proposed Freeze Exceptions
17:08:37 <adamw> #info 8 Accepted Freeze Exceptions
17:08:50 <adamw> who wants to be that most-prized of all jobs, the secretary?
17:09:16 <coremodule> adamw, I will do it!
17:09:45 <adamw> #info coremodule will be the great and powerful secretary
17:09:59 <adamw> alrighty, so starting in with the proposed blockers
17:10:01 <adamw> morning kevin
17:10:06 <adamw> #topic (1370073) [abrt] gnome-shell: _g_log_abort(): gnome-shell killed by SIGTRAP
17:10:06 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1370073
17:10:06 <adamw> #info Proposed Blocker, gnome-shell, NEW
17:10:18 <adamw> halfline: around, by any chance? get any further with this one yet?
17:10:38 <adamw> so i proposed this one as openQA hits it often enough for me to be nervous, but with what we've figured out about it so far i'm *probably* -1
17:11:53 <kparal> this kills whole session, right?
17:12:01 <pschindl> yes
17:12:37 <sgallagh> Have we seen this in the wild outside of OpenQA?
17:12:48 <kparal> pschindl has, according to the bug
17:12:49 <sgallagh> NM
17:12:53 <kparal> I didn't
17:13:09 <pschindl> I haven't seen it on my working laptop. But it happened to me when I installed a clean 25 with updates on my home laptop.
17:13:16 <kparal> ah
17:13:24 <adamw> the key thing is that, we *think*, it's related to first login
17:13:25 <kparal> so the theory about clean installs might be right
17:13:29 <adamw> either g-i-s or something else that happens on first login
17:13:42 <adamw> which would obviously explain why none of us sees it on day-to-day use systems
17:13:55 <kparal> and it somewhat sucks to crash on first login
17:13:59 <adamw> i checked all the openQA cases i could find and they were all on first login
17:14:00 <sgallagh> Has anyone seen it happen within a live session?
17:14:09 <pschindl> It didn't happen immediately. I worked for a while.
17:14:10 <adamw> sgallagh: don't think we've had that, no, it's really first login *after install*
17:14:15 <adamw> pschindl: hmm, that's interesting
17:14:15 <sgallagh> hmm
17:14:38 <adamw> i was about to say 'in openQA it always happens right away', but of course few of the openQA tests run for very long after login at all
17:14:38 <jforbes> That doesn't seem to set a good first impression
17:14:59 <pschindl> It happened after I downoaded some file in firefox and I tried to close firefox
17:15:10 <sgallagh> /me goes to do a clean install on a spare laptop
17:15:24 <sgallagh> Do we want to investigate this a bit and loop back around to it?
17:15:24 <adamw> in openQA this happens something like...i'd say 10% of the time
17:15:36 <adamw> (i'd have to go crunch some numbers to give a really accurate one, that's a ballpark)
17:15:43 <pschindl> That's not small number.
17:15:46 <adamw> sgallagh: you mean, within the meeting?
17:15:50 <sgallagh> yes
17:16:07 <adamw> mmm, sure. but i dunno how much investigation we'll get done
17:16:10 <sgallagh> OK
17:16:33 <sgallagh> I'm wondering how likely it is to hit on real hardware
17:16:40 <adamw> fair enough
17:16:49 <kparal> if it's 10% and really hard to solve, I'd be OK with not blocking.
17:16:56 <sgallagh> But 10% in openQA is concerning
17:17:01 <kparal> but I wouldn't argue against blocking either
17:18:11 <adamw> yeah, it's definitely a 'last blocker smell test' kind of an issue
17:18:25 <adamw> especially since it doesn't look like it's a trivial fix (on friday it had both halfline and mclasen stumped)
17:18:55 <adamw> well, we can circle back to it, i guess
17:19:04 <sgallagh> /me is pulling the latest nightly to test with
17:19:07 <adamw> #info this is a tricky one and people are going to go run some bare metal installs and see if they hit it, we'll circle back
17:20:25 <adamw> zoiks, something weird happened to today's openqa workstation live run...
17:20:45 <sgallagh> adamw: weirder than usual?
17:20:50 <adamw> heh
17:20:56 <adamw> looks like more asset cleanup shenanigans
17:21:02 <adamw> anyhow. next bug
17:21:10 <adamw> #topic (1390610) LibreOffice Impress crashes when you move slide pane into a separate window on Wayland
17:21:10 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1390610
17:21:10 <adamw> #info Proposed Blocker, libreoffice, VERIFIED
17:21:31 <cmurf> shenanigans
17:22:17 <kparal> this might be a bit controversial
17:22:28 <sgallagh> I'm kind of 0 on blocker status, but I'm fine with +1 FE
17:22:34 <kparal> however, if we just agree on +1FE and push it, we don't need to argue about a blocker
17:22:37 <kparal> :)
17:22:42 <Southern_Gentlem> -1 blocker +1 fe
17:22:45 <pschindl> +1 FE
17:23:17 <cmurf> +1 FE, -1 blocker
17:23:33 <jkurik> -1 blocker +1 fe
17:23:33 <kparal> for the record, I'm inclined to +1 blocker
17:23:38 <garretraziel> -1 blocker, +1 fe
17:23:42 <adamw> FE for sure, i'm about a 0 on blocker.
17:23:47 <garretraziel> kparal: why?
17:23:50 <cmurf> it is a crash, which is bad
17:24:00 <kparal> because it's not just a crash. it makes OO unusable
17:24:01 <garretraziel> true
17:24:10 <cmurf> but there's a fix to avoid the crash
17:24:19 <kparal> if you start it again, the pane if floating, obscuring your view, and it crashes again as soon as you touch it
17:24:33 <garretraziel> yeah, I rember now, you cannot open LO anymore, can you
17:24:34 <cmurf> yeah it's not pretty
17:24:36 <garretraziel> yeah
17:24:42 <kparal> I don't think anybody knows the right shortcut, and removing all your configuration files is... ugly
17:24:57 <kparal> garretraziel: you can open it, but you can no longer touch the floating pane
17:25:00 <cmurf> if it were X, I'd say block
17:25:10 <kparal> so even if it is floating in the middle of the screen, you can move it away
17:25:23 <sgallagh> kparal: Can you boot to X to fix it?
17:25:33 <kparal> sgallagh: yes, that should work
17:25:44 <kparal> but again, it's non-obvious
17:25:50 <sgallagh> kparal: I'd be okay with that as a workaround in Common Bugs
17:26:04 <kparal> it's a non-issue anyway, as long as we give it +1 FE
17:26:14 <sgallagh> /me suspects a lot of people are going to drop back to X the first time they have any inconvenience at all, honestly
17:26:17 <kparal> it's been fixed
17:26:19 <cmurf> just like owies when ripping off bandaides - but moom it hurts! why?! it HURTS! MOM!!!!!
17:26:53 <cmurf> shhh honey here's another bandaid
17:27:00 <sgallagh> Is there anyone here who *doesn't* think it deserves at least FE?
17:27:38 <cmurf> only if the fix ends up worse than the described current behavior...
17:28:05 <sgallagh> Doesn't everyone just use Google Docs now anyway?
17:28:05 <sgallagh> /me runs
17:28:32 <jkurik> I will give it FE to push the fix into the next compose and move on
17:28:46 <cmurf> Google annoyed me with their late and tepid support of ODF
17:29:55 <adamw> proposed #agreed 1390610 - delay blocker decision, AcceptedFreezeException - there's some disagreement about whether this is serious enough to merit blocker status, but as there's already a tested fix, we'll simply grant it FE status and move on
17:30:02 <kparal> ack
17:30:03 <sgallagh> ack
17:30:15 <jkurik> ack
17:30:17 <garretraziel> ack
17:30:51 <pschindl> ack
17:31:17 <cmurf> it's a trap! he said in lieu of ack!
17:32:31 <dgilmore> ack
17:32:37 <adamw> #agreed 1390610 - delay blocker decision, AcceptedFreezeException - there's some disagreement about whether this is serious enough to merit blocker status, but as there's already a tested fix, we'll simply grant it FE status and move on
17:32:47 <adamw> #topic (1390607) LibreOffice Impress (and stripped down native gtk demo) doesn't run presentation correctly on Wayland
17:32:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1390607
17:32:47 <adamw> #info Proposed Blocker, mutter, NEW
17:33:00 <cmurf> this is not a duplicate
17:33:17 <dgilmore> is libreoffice-impress in the workstation live?
17:33:47 <sgallagh> dgilmore: Yes
17:33:56 <sgallagh> (I just confirmed that)
17:34:05 <cmurf> Yes, it appears in GNOME as "LibreOffice I..."
17:34:16 <kparal> I found a workaround in c11. not sure it will work every time
17:34:16 <dgilmore> okay
17:34:21 <cmurf> versus "LibreOffice..." and "LibreOffice C..."
17:34:33 <dgilmore> cmurf: that sounds useful
17:34:37 <sgallagh> cmurf: Depends on your screen resolution, I think. Mine gets all the way to Impr...
17:34:41 <cmurf> and "LibreOffice D..."
17:34:42 <kparal> :D
17:34:45 <adamw> yeah, i get 'Impr"
17:35:09 <cmurf> well i have the funky medium res screen but with big text enabled
17:35:12 <sgallagh> Considering the huge amount of empty space between icons, you'd think it could just wrap...
17:35:32 <sgallagh> irrelevant though
17:35:47 <sgallagh> This sounds like pretty much the whole point of Impress isn't working under Wayland, though
17:36:01 <cmurf> yup
17:36:02 <sgallagh> /me wonders why no one spotted this sooner...
17:36:35 <cmurf> so I'd say it's tentatively a blocker, and Workstation WG needs to decide what to do
17:36:36 <kparal> because noone gave presentation on wayland yet
17:36:45 <kparal> until Jiri Eischmann this weekend :)
17:37:00 <cmurf> a.) ship it broken, b.) fix it c.) yank it
17:37:14 <sgallagh> I don't think tentatively at all. This is +1 blocker under the basic functionality criterion
17:37:45 <cmurf> yeah well, I'm cutting Wayland a lot of slack
17:37:52 <sgallagh> So that leaves B) or C) there.
17:38:12 <cmurf> if it were X, it's a blocker, if it's Wayland, then I'm mostly deferring to Workstation WG if they really wanna block on it
17:38:15 <sgallagh> cmurf: Sure, but this is the whole purpose of presentation software. If it doesn't work, it needs to be fixed or removed from the default set
17:38:39 <sgallagh> Wayland is the default environment in F25, so I'm giving it more weight than in previous releases
17:38:44 <kparal> it sounds like the fix should not be hard
17:38:49 <sgallagh> (Much too late to change our minds on that)
17:39:18 <cmurf> I'd rather see Impress removed than either revert Wayland to X, or delay the release - but again it's up to the WG
17:39:22 <cmurf> anyway +1 blocker
17:39:24 <Kevin_Kofler> If things are still broken under Wayland, they should revert the default to X, it would be one possible way to address such blockers.
17:39:29 <adamw> i think i'm a weak +1 blocker on this.
17:39:49 <dgilmore> sgallagh: I would guess no one tried
17:39:52 <kparal> I'm also weak +1
17:40:12 <rtcm> fwiw, the LO side is pushed and I can push the mutter side right now - was just waiting for upstream review but the patch is simple and works in my testing so
17:40:14 <cmurf> floating point blocker values
17:40:14 <adamw> Kevin_Kofler: switching to X by default would be a legitimate resolution for any wayland-specific blocker, yes. deciding on resolutions is usually out of the scope of this meeting, though
17:40:17 <dgilmore> I am +1 blocker also
17:40:33 <kparal> rtcm: thanks for the update
17:40:51 <pschindl> +1
17:41:03 <adamw> proposed #agreed 1390607 - AcceptedBlocker (Final) - this use of Impress is so common that we consider it to be part of 'basic functionality', it's pretty much how everyone gives presentations, so 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."
17:41:13 <kparal> ack
17:41:15 <sgallagh> ack
17:41:18 <mboddu> ack
17:41:19 <sgallagh> actually, patch
17:41:21 <adamw> cmurf: "it's 0.867 blocker"
17:41:25 <adamw> sgallagh: drop the extra ", i know
17:41:26 <cmurf> awesome sauce
17:41:26 <pschindl> ack
17:41:26 <jkurik> ack
17:41:32 <sgallagh> adamw: No, other patch
17:41:37 <adamw> go for it
17:41:42 <dgilmore> ack
17:42:16 * cmurf heard a guy say awesome sauce for the first time last night at a bar to the bartender
17:42:52 <cmurf> But hey I'm in California which is sorta like a different country.
17:43:04 <sgallagh> OK, I can't find a good way to note that the Wayland aspect is important.
17:43:12 <sgallagh> So I'll just ack
17:43:33 <cmurf> supplementary comment?
17:44:25 <sgallagh> Probably not important if a fix is impending anyway
17:45:08 <adamw> #agreed 1390607 - AcceptedBlocker (Final) - this use of Impress is so common that we consider it to be part of 'basic functionality', it's pretty much how everyone gives presentations, so 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."
17:45:16 <adamw> #topic (1389130) Existing RAID or LVM metadata can cause various types of install failures.
17:45:17 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1389130
17:45:17 <adamw> #info Proposed Blocker, python-blivet, POST
17:45:45 <sgallagh> Didn't we have this one last release too?
17:46:22 <kparal> we always have raid bugs
17:46:25 <coremodule> It does sound familiar.
17:47:07 <cmurf> I'm laughing at this bug...
17:47:19 <cmurf> in a manaical way of course.
17:48:06 <cmurf> where is the nominating criterion?
17:48:48 <cmurf> OK comment 11
17:48:55 <cmurf> it was just set as blocking by upstream
17:49:16 <cmurf> i guess the obvious criterion is the catch all one...
17:49:54 <adamw> sgallagh: #c10: "I think this has been fixed at least once before."
17:50:34 <adamw> i think i'm +1 to this, though i wish we'd started working on it two weeks ago.
17:51:04 <cmurf> I want to be -1
17:51:38 <adamw> cmurf: there is clearly a case here where you just try to do a RAID install over the top of an existing Fedora RAID install and anaconda crashes.
17:51:39 <sgallagh> I don't get a sense of how likely it is that a user would hit this
17:51:42 <adamw> that's clearly a blocker to my mind.
17:51:47 <sgallagh> ah, ok
17:51:52 <sgallagh> In that case yes. +1 blocker
17:51:53 <adamw> sgallagh: this is all based on reports from an actual user in IRC last week, so, very likely. :P
17:52:03 <jkurik> I am +1 to block. As we already have a patch, lets hope it is fixed prior the final compose
17:52:32 <cmurf> I guess ther's a new LVM behavior or something? Or it's obscure despite an actual user on IRC reporting it just last week.
17:52:44 <garretraziel> +1 blocker
17:53:28 <adamw> cmurf: it's libblockdev changes, i think.
17:53:42 <sgallagh> cmurf: Or more likely, people running RAID tend not to do overwriting updates on prereleases?
17:53:53 <sgallagh> At least as a demographic
17:53:58 <mclasen_> there's always an easy fix for application crashes or misbehaviors under wayland: run them under xwayland
17:54:17 <adamw> mclasen_: is LO wayland-native?
17:54:25 <adamw> i thought it was already running in xwayland...
17:54:30 <cmurf> yeah I just want custom partitioning gone, it's an out of scope conversation
17:54:37 <mclasen_> I assumed so, otherwise why would it have wayland-specific crashes ?
17:54:41 <cmurf> i understand it's a blocker, by the book
17:54:51 <adamw> mclasen_: eh, i dunno. we're past that bug now anyhow
17:54:58 <kparal> adamw: it's native
17:55:05 <adamw> so we have about +3 now
17:55:05 <adamw> kparal: ah k
17:55:05 * mclasen_ shuts up
17:55:13 <adamw> mclasen_: :P sorry, just trying not to get crosswise
17:55:35 <adamw> any other votes?
17:56:06 <pschindl> I'm +1 too
17:58:18 <adamw> alright, that seems like enough
17:58:33 <kparal> +1
17:59:47 <adamw> proposed #agreed 1389130 - AcceptedBlocker (Final) - this is a violation of Beta criterion "When using the custom partitioning flow, the installer must be able to: Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions"
18:00:10 <mboddu> ack
18:00:28 <sgallagh> ack
18:00:49 <jkurik> ack
18:00:52 <cmurf> ack
18:00:55 <adamw> #agreed 1389130 - AcceptedBlocker (Final) - this is a violation of Beta criterion "When using the custom partitioning flow, the installer must be able to: Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions"
18:01:53 <adamw> #topic (1390027) Anaconda should tell the user it is running fsck, possibly allow to skip
18:01:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1390027
18:01:53 <adamw> #info Proposed Blocker, python-blivet, NEW
18:01:56 <adamw> so...this.
18:02:11 * cmurf snickers at adamw
18:02:37 <jkurik> was it possible to skip fsck in the previous releases ?
18:02:42 <cmurf> no
18:02:44 <kparal> now I finally know why is anaconda so slow
18:02:47 <cmurf> yes
18:02:54 <kparal> was fsck run even in previous releases?
18:02:54 <cmurf> I agree with comment 3
18:02:56 <adamw> this has been kind-of-ongoing for a few releases now
18:03:03 <cmurf> +1 blocker, get rid of it
18:03:24 <adamw> kparal: yes, i'm trying to dig up when this became an issue exactly, but it's not just 25
18:03:31 <cmurf> it does in fact allow disks other than those selected to be affected by the installation process
18:03:33 * adamw is asking dlehman for his opinion on this
18:03:50 <sgallagh> When does the fsck occur?
18:03:51 <cmurf> there is no good reason to force running fsck
18:04:06 <cmurf> always on every attached ext34 volume
18:04:13 <kparal> is there any way to avoid 7.5 hour long fsck for large filesystems?
18:04:20 <adamw> so, https://bugzilla.redhat.com/show_bug.cgi?id=1170803 was one of the previous bugs
18:04:21 <cmurf> if you have a 20TB ext4 volume, it will do a 3 day fsck
18:04:35 <kparal> fun
18:04:36 <sgallagh> I agree it isn't a good thing, but I'm not sure it's blocker-worthy. Particularly if it's an old problem
18:04:43 <adamw> this is another one where i wish someone would've proposed it three weeks ago...
18:05:15 <cmurf> I think it meets the criterion
18:05:17 <kparal> the F21 bug claims to be fixed
18:05:36 <sgallagh> kparal: It notes that it may have been reintroduced when blivet was split out
18:05:46 <kparal> and it was rejected as a blocker in the past
18:05:50 <cmurf> "Disks not selected as installation targets must not be affected by the installation process in any way. "
18:05:57 <adamw> kparal: AHA! this was all your fault in the first place! https://bugzilla.redhat.com/show_bug.cgi?id=1162215
18:06:02 * adamw hangs note of shame on kparal
18:06:08 <sgallagh> Is it doing auto-repair?
18:06:18 <sgallagh> If not, then fsck isn't actually "affecting" the FS
18:06:28 <kparal> ah right, my corner cases
18:07:04 * kparal proudly shows off the note
18:07:24 <cmurf> A 20 minute read only fsck is still affecting those targets - the entire system is hung up while the fsck happens...
18:07:38 <cmurf> But I'm pretty sure this is a preen.
18:08:23 <sgallagh> cmurf: I would assume that the term "affect" really should have been "alter"
18:08:50 <adamw> yeah, that's what it means.
18:08:58 <cmurf> Preen will alter
18:09:02 * adamw pokes through blivet code
18:09:32 <cmurf> There's no reason to do this so indiscriminately.
18:09:41 <cmurf> If the file system were that busted it wouldn't even mount.
18:10:28 <adamw> so basically the offending code here is probably https://github.com/rhinstaller/blivet/blob/2.0-devel/blivet/formats/fs.py#L122-L125 .
18:10:34 <sgallagh> cmurf: I don't disagree with fixing this. I disagree with the lack of a fix blocking the release.
18:10:42 <adamw> any call to update_size_info() will run a fsck, if it's possible for that filesystem.
18:11:40 <cmurf> There is a fix, Eric Sandeen removed the fsck requirement from ext3/4 resizes two years ago.
18:12:24 <cmurf> Actually the fsck requirement to poll for minimum resize size.
18:12:41 <cmurf> The fsck itself still gets done prior to the resize on a specifically chosen ext3/4 file system.
18:13:01 <cmurf> But the user hasn't asked for a resize on anything - and yet the fsck is still being done.
18:13:19 <adamw> cmurf: yes, i am reading through that at present to see if it's all entirely true.
18:14:09 <cmurf> lack of faith disturbing
18:14:36 <sgallagh> /me Force-chokes cmurf
18:15:19 <sgallagh> As an aside: I installed last night's Workstation Live on a laptop, logged in, did g-i-s, poked around on FF. No failures.
18:15:26 <sgallagh> I can reinstall and try again, I guess.
18:19:06 <kparal> so
18:20:17 <kparal> -1, sorry, too close to release, maybe next time?
18:20:29 <adamw> yeesh, give a guy a chance to research heah
18:22:52 <cmurf> From the program.log you can see it does e2fsck -f -p -C 0  on every ext234 volume it finds (presumably by libblkid)
18:23:00 <cmurf> -p is preen which is automatically fix
18:23:14 <cmurf> -f is force, even if the fs is marked clean
18:24:11 <adamw> yes, that's true.,
18:24:29 <adamw> i'm currently looking into two things:
18:24:35 <adamw> 1) how this behaved between f22 and f 24
18:24:46 <adamw> 2) whether it would actually be safe to remove the call for what blivet needs to do
18:25:46 <cmurf> it runs this on the live media image
18:25:58 <cmurf> it's wholly indiscriminate
18:27:56 <cmurf> i've never not seen e2fsck run on the live rootfs image, or any overlay derivative
18:29:13 <adamw> can't parse that last one.
18:30:01 <cmurf> For a very long time, well before F22, e2fsck has been run on the rootfs.img on Lives, and every other ext234 file system found.
18:30:36 <adamw> cmurf: okay. we know this was happening before f22.
18:31:09 <adamw> the reason i said 'since f22' is that that's when the change to resize2fs was merged and #1170803 was claimed fixed.
18:31:19 <adamw> hmm
18:31:35 <adamw> so it seems like the e2fsprogs update that removed the *requirement* for fsck to be run was marked as fixing the bug
18:31:38 <cmurf> Well the resize2fs change didn't also cause blivet to stop calling for e2fsck.
18:31:48 <adamw> when it fact it never did - it would just have allowed anaconda to not do the fsck any more. but no-one ever changed anaconda.
18:31:54 <cmurf> That's right, the requirement was removed. But blivet itself never changed.
18:32:24 <adamw> tracing the code through blivet/anaconda history is tricky, but i don't think it ever got changed.
18:32:48 <adamw> so, that would mean this has been happening for every release since F21.
18:33:14 <cmurf> Right it's not a new problem. It's not a regression.
18:33:24 <sgallagh> Which leads me further down the path of: "It sucks, but let's not block on it"
18:33:33 <adamw> which is kinda what dlehman's saying.
18:33:51 <adamw> though yeah, the fact that it will actually change non-involved filesystems is kinda bad, even if e2fsck claims it only does 'safe' fixes.
18:34:14 <jkurik> yeah, I am -1 to block here as this issue is in for several releases already and we are too close to the final release
18:35:27 <cmurf> Add it to the new future priority fixes pile?
18:35:31 <sgallagh> For the record, I'm also -1 FE as I'm concerned that poking around here will introduce other issues.
18:36:28 <cmurf> Not running fsck on things not needing fsck in the first place is a big plus everyone gets right off the bat by the live image not being fsck'd unnecessarily anymore.
18:37:42 <sgallagh> cmurf: +1 to adding it to the priority fixes pile
18:37:47 <adamw> so.....i'm about 97% sure that it'd be safe to fix this.
18:37:51 <cmurf> Let the file system and file system devs determine when fsck is to be run rather than doing this indicscriminate -f -p nonsense.
18:38:34 <adamw> cmurf: calling it nonsense is going too far. we *were* letting the 'file system and file system devs determine' it. and they were saying it had to be done if you wanted to know the minimum size of the filesystem. which we did.
18:38:47 <adamw> that is no longer the case and we should change it, but it was not 'nonsense'.
18:39:10 <cmurf> adamw: wel they admitted the check just to determine min resize size was archaic and should have been removed a long time ago
18:39:17 <adamw> (though probably shouldn't have been in __init__ ever, but that might've been the safest way to fix the blocker at the time)
18:39:51 <adamw> cmurf: which would've been more likely to happen if the e2fsprogs update hadn't been incorrectly set to close the bug.
18:39:56 <adamw> cmurf: devs have enough *open* bugs to worry about without looking at every closed bug to see if it should be open.
18:40:10 <cmurf> And yes trying to force preen a read only file system? Kinda very much nonsense.
18:40:18 <adamw> anyhow
18:41:20 <cmurf> Ok so obviously there's no momentum to make it a blocker even though it meets the alteration requirement people were saying needed to be true to make it a blocker...
18:41:23 <cmurf> so just move on.
18:41:31 <cmurf> punt or whatever
18:42:10 <sgallagh> cmurf: I don't think this would survive a Go/No-Go meeting.
18:42:17 <sgallagh> Given that it's been this way for years
18:42:43 <sgallagh> The world didn't end in that time, it can survive one more release. But yes, let's ask for that to be prioritized
18:42:50 <cmurf> That's all the more reason why it should just get fixed, so we aren't wasting another group's 41 minutes of their lives down the road.
18:43:41 <adamw> proposed #agreed 1390027 - RejectedBlocker (Final), RejectedFreezeException (Final) - this has in fact been broken since Fedora 21, and was rejected as a blocker for Fedora 22. Though we note it causes e2fsck to perform 'safe' fixes on non-selected filesystems, as well as taking a long time if large ext2/3/4 filesystems are present, we don't see sufficient reason to change that decision or change this as an FE at this time
18:45:20 <sgallagh> ack
18:45:23 <coremodule> ack
18:45:29 <dowdle> It would be nice if the fact that it is doing that was in the release notes or common bugs.
18:46:03 <cmurf> It'd be nice if it said what it was doing rather than just act like it's frozen while doing a 20+ minute fsck on everything...
18:46:24 <adamw> yeah, commonbugs would be good.
18:46:34 <adamw> cmurf: changing that is about as disruptive as trying to fix it, really.
18:46:40 <adamw> it's never good to try and wedge in new UI at the last minute.
18:47:29 <cmurf> It wasn't a feature proposal.
18:47:52 <jkurik> ack
18:48:30 <kparal> ack
18:49:32 <kparal> adamw: I'm not sure why you closed it as dupe, but did not reopen the other bug
18:50:06 <kparal> we need at least one of them open
18:50:21 <adamw> #agreed 1390027 - RejectedBlocker (Final), RejectedFreezeException (Final) - this has in fact been broken since Fedora 21, and was rejected as a blocker for Fedora 22. Though we note it causes e2fsck to perform 'safe' fixes on non-selected filesystems, as well as taking a long time if large ext2/3/4 filesystems are present, we don't see sufficient reason to change that decision or change this as an FE at this time
18:50:27 <adamw> kparal: i'm re-opening the other bug now
18:50:29 <adamw> with a comment explaining why
18:50:30 <kparal> ok
18:50:35 <adamw> gimme a break here, lot of balls in the air
18:50:36 <kparal> please slap commonbugs on it
18:50:48 <adamw> #topic (1350054) Refuses to let systemd fix label of /dev/shm/lldpad.state on boot
18:50:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1350054
18:50:48 <adamw> #info Proposed Blocker, selinux-policy, ON_QA
18:50:53 <adamw> you talk about that while i work :P
18:51:34 <cmurf> Also in the category of world not ending bugs probably wouldn't survive go/no-go, but still meets the blocker criterion by the book. +1 blocker.
18:53:14 <kparal> this is just in journal, no notification about it, right?
18:53:22 <kparal> I don't remember seeing any notification
18:53:29 <sgallagh> kparal: It shows up on the screen before dracut takes over
18:53:36 <kparal> right
18:53:38 <sgallagh> But I haven't seen it turn up as a GNOME notification
18:53:44 <kparal> flashes through
18:54:13 <sgallagh> It also didn't appear on boot of the live image I just started
18:54:17 <kparal> I'm not that concerned about an error that just flashes through
18:54:27 <cmurf> I have intermittantly seen it cause GNOME sealert notifications
18:54:27 <sgallagh> Not sure if that means the pending update was already included.
18:54:30 <sgallagh> /me checks
18:54:54 <sgallagh> I'm going to stick with -1 blocker, +1 FE on the grounds that it really wouldn't survive the "last blocker" test
18:55:09 <kparal> most of the polish criteria wouldn't
18:55:27 <jkurik> I am +1FE as well
18:55:27 <kparal> if cmurf says it shows up in gnome, I'm +1
18:55:39 <kparal> otherwise I don't mind
18:55:47 <sgallagh> kparal: Which suggests that maybe the polish criterion shouldn't be on the blocker list...
18:56:09 <sgallagh> Given that a fix is prepared, it's probably irrelevant as long as we agree on at least FE
18:56:17 <kparal> maybe. or we should be strict to enforce it :)
18:56:44 <sgallagh> I don't like setting a precedent I wouldn't back up on a future discussion, personally
18:56:46 <cmurf> Well it sometimes shows up in gnome, I just don't understand why the notification is transient.
18:57:22 <cmurf> And I've also noticed it doesn't notify with live boots recently (last 2-3 weeks I guess)
18:57:27 <kparal> personally I never see it, but I'm running in permissive mode
18:57:31 <adamw> sgallagh: i still believe the criterion is a good one and will stand by it. I'm +1 on this. we shouldn't ship stuff that shows the user errors right out of the box.
18:57:38 <cmurf> But does sometimes after subsequently installed.
18:57:46 <adamw> sgallagh: i've stood behind this criterion on multiple occasions in the past
18:57:51 <sgallagh> ok
18:58:05 <sgallagh> I won't fight hard about this one. It appears to be fixed anyway
18:58:28 <cmurf> It's definitely always in the sealert application  - but (hand waive) I think I only get a notification in GNOME 1 in 4 times.
18:59:14 <adamw> cmurf: is that 1 in 4 fresh boots / fresh installs?
18:59:21 <cmurf> boots
18:59:24 <adamw> or 1 in 4 boots of a system where it's already happened?
18:59:29 <cmurf> dunno
18:59:37 <adamw> because i think it's 'normal' that sealert doesn't consistently re-notify you of the same thing happening.
18:59:43 <cmurf> sample size is too small, transient behavior is too varied
18:59:51 <cmurf> oh ok
18:59:54 <cmurf> well that might be related
19:00:34 <sgallagh> adamw: I get constantly re-alerted about SELinux alerts
19:00:53 <adamw> me too, but i don't think it's 100% of the time, i think there's some kinda fudging going on
19:01:01 <adamw> but meh, who knows. maybe it's a timing thing. maybe it's ghosts.
19:01:06 <adamw> let's just vote something and move on!
19:01:06 <sgallagh> I think it caps at once per hour or something
19:01:19 <cmurf> ghosts
19:01:21 <sgallagh> I'll move to 0 and not interfere with the decision
19:03:06 <cmurf> we're at +3
19:05:23 <jkurik> may I still be -1 to block and +1 to FE ?
19:05:49 <adamw> you can, but then we're stuck. :P
19:06:07 <sgallagh> adamw: AcceptedFE, PuntedBlocker?
19:06:11 <adamw> if anyone is gonna vote -1 i'm gonna ask that they justify it with something other than 'i don't agree with the criterion', because that is not a legitimate reason for a -1
19:06:16 <sgallagh> I mean, if the fix is ready, it's kind of academic...
19:06:21 <adamw> that's possible, yeah.
19:08:10 <cmurf> Whenever I ask for justification other than non-agreement with the criterion all I get is crickets. So why would this one be any different?
19:08:28 <adamw> heh
19:08:33 <adamw> okay, let's fudge it
19:08:35 <adamw> we all like fudge
19:08:46 <cmurf> Fudge yes.
19:08:58 <sgallagh> WTFudge?
19:08:58 <jkurik> cmurf: what does it mean to get crickets ?
19:08:59 <cmurf> Fudging, err, seems unrelated but sounds good.
19:09:17 <sgallagh> jkurik: Meaning all you hear is the sound of crickets chirping. No voices.
19:09:31 <adamw> proposed #agreed 1350054 - AcceptedFreezeException (Final), delay blocker decision - there's some disagreement about whether this is consistently-encountered enough to qualify as a blocker; as there's a fix we accept it as a freeze exception and delay the blocker decision in the expectation it will be fixed and we won't have to make a decision
19:09:35 <cmurf> jkurik: idiom, related to comedy when no one laughs it's so silent that all you hear are the crickets chirping.
19:09:54 <jkurik> ok, thanks for the explanation :)
19:09:54 <sgallagh> adamw: ack
19:10:12 <jkurik> ack
19:10:26 <kparal> ack
19:12:17 <garretraziel> ack
19:13:10 <adamw> #agreed 1350054 - AcceptedFreezeException (Final), delay blocker decision - there's some disagreement about whether this is consistently-encountered enough to qualify as a blocker; as there's a fix we accept it as a freeze exception and delay the blocker decision in the expectation it will be fixed and we won't have to make a decision
19:13:25 <adamw> #topic (1391522) unknown input device type 'virtio1.0-input'
19:13:25 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1391522
19:13:25 <adamw> #info Proposed Blocker, virt-manager, VERIFIED
19:13:35 <kparal> +1
19:13:41 <adamw> i'm actually pretty +1 on this, it's pretty solidly in the 'self-hosting virt' criterion.
19:14:56 <jkurik> +1 to block
19:15:12 <garretraziel> sure, +1
19:15:14 <garretraziel> blocker
19:15:51 <sgallagh> +1 blocker
19:16:06 <cmurf> interesting
19:16:33 <sgallagh> cmurf: Virt of the same version didn't work *at all*.
19:16:53 <adamw> does this affect boxes too, out of interest/
19:16:54 <adamw> ?
19:17:14 <sgallagh> adamw: I haven't tested, but I would doubt it.
19:17:26 <sgallagh> This happens at the virt-manager/virt-install layer, not the libvirt laye
19:17:36 <sgallagh> I don't think Boxes calls the same functions
19:17:37 <cmurf> yeah that's what i'm wonder, if boxes is affected
19:17:41 <adamw> proposed #agreed 1391522 - AcceptedBlocker (Final) - this is a violation of "The release must be able host virtual guest instances of the same release" in the case of using virt-manager, which is one of the two prime front ends for the 'Fedora virt stack'
19:17:52 <adamw> cmurf: i'm still +1 even if it isn't, though, i was just curious.
19:17:56 <kparal> ack
19:17:57 <cmurf> yeah
19:18:00 <sgallagh> ack
19:18:02 <jkurik> ack
19:18:09 * jkurik has to leave
19:18:54 <adamw> thanks jkurik
19:18:57 <adamw> that was the last proposed blocker
19:18:59 <adamw> #chair kparal
19:18:59 <zodbot> Current chairs: adamw jkurik kparal sgallagh
19:19:06 <adamw> (to replace jkurik)
19:19:11 <jkurik> :)
19:19:12 <adamw> #agreed 1391522 - AcceptedBlocker (Final) - this is a violation of "The release must be able host virtual guest instances of the same release" in the case of using virt-manager, which is one of the two prime front ends for the 'Fedora virt stack'
19:19:13 <jkurik> bye
19:19:25 <sgallagh> Did we want to circle back on the SIGTRAP one?
19:19:31 <sgallagh> Or do that later?
19:19:42 <adamw> uh, either way, i guess.
19:20:21 <adamw> let's circle back now before people die of boredom
19:20:35 <adamw> #topic (1370073) [abrt] gnome-shell: _g_log_abort(): gnome-shell killed by SIGTRAP
19:20:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1370073
19:20:35 <adamw> #info Proposed Blocker, gnome-shell, NEW
19:21:07 <sgallagh> I've been doing repeated installs on an older laptop I had around. I have yet to encounter this bug on a fresh install
19:21:18 <adamw> welp, nothing has really changed about this in the last hour or so, but my instinct was always that it wouldn't quite pass the last blocker test, so -1. if it was hitting like 30% of installs i'd probably be +1./
19:21:19 <sgallagh> I've done four iterations thus far.
19:21:47 <sgallagh> It doesn't recur after the initial crash, right?
19:22:03 <adamw> i don't have enough data to say anything for sure, but that seems likely to be the case.
19:22:36 <sgallagh> OK, then. Bugs happen, we can't catch everything. I'd be open to considering an FE if a fix came up, but -1 blocker from me
19:23:45 <cmurf> did i just walk through the looking glass? this isn't the same bug we started with is it?
19:24:03 <cmurf> oh it is
19:24:15 <cmurf> time for more fudge
19:24:21 <adamw> yes, we're cycling back to it like we said we would.
19:24:36 <adamw> either that, or you're stuck in a blocker bug meeting time loop
19:24:37 <adamw> better get more gin
19:24:59 <cmurf> gin and fudge
19:25:06 <pschindl> I'm -1 too. I met it just once (not even a 10%) on just one machine.
19:25:28 <sgallagh> niaga kcab dna ereht
19:25:37 <cmurf> tell you what, if i'm not cc'd on that bug, i'm -1
19:25:42 <cmurf> and if i am, i'm -1
19:27:07 <cmurf> ok i'm not cc'd on it, thus haven't hit it, thus definitely -1
19:28:51 <garretraziel> cmurf: you didn't gave it much choice, did you :-)
19:31:25 <adamw> are we +1 FE?>
19:32:02 <cmurf> +1FE
19:32:44 <cmurf> +1 to being +1 at the top half of blocker review and -1 at the bottom half, because U.S. Ship It.
19:32:52 <sgallagh> adamw: An FE means we'll consider it, not that we'll definitely take it, right?
19:33:14 <adamw> yes
19:33:20 <sgallagh> Then sure
19:33:25 <coremodule> Going mobile, still here.
19:33:55 <adamw> proposed #agreed 1370073 - RejectedBlocker (Final), AcceptedFreezeException (Final) - this is unfortunate if you run into it, but on current data we don't think it happens quite enough to constitute a violation of the criteria
19:33:57 <sgallagh> I am wary of any fix in this space though, given ithe risk
19:34:03 <sgallagh> ack
19:34:11 <cmurf> FE means adamw tests it and if it breaks more things the dev owes him gin and fudge
19:36:23 <pschindl> ack
19:37:47 <cmurf> ack
19:38:23 <adamw> #agreed 1370073 - RejectedBlocker (Final), AcceptedFreezeException (Final) - this is unfortunate if you run into it, but on current data we don't think it happens quite enough to constitute a violation of the criteria
19:38:57 <kparal> ack
19:39:09 <adamw> alright, sorry for the slow meeting folks, but time for the proposed FEs
19:39:24 <adamw> we have 10, so i'll prioritize those with fixes available first
19:40:04 <adamw> #info moving to proposed freeze exceptions
19:40:04 <adamw> #topic (1335046) TypeError: Argument 0 does not allow None as a value
19:40:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1335046
19:40:05 <adamw> #info Proposed Freeze Exceptions, anaconda, POST
19:40:19 <adamw> s390 stuff, "The fix for this is simple and isolated to s390x-specific code." - +1
19:40:31 <sgallagh> +1
19:40:38 <coremodule> +1 here.
19:40:44 <garretraziel> +1
19:40:50 <adamw> in fact, full disclosure, this is basically a rubber stamp
19:40:52 <kparal> +1
19:41:04 <adamw> mkolman wanted to get home so i told him he could just assume we were going to +1 this and include it in the build. :P
19:41:19 <pschindl> +1
19:41:21 <cmurf> from fudge to rubber, we're regressing to the inedibles
19:41:38 <adamw> proposed #agreed 1335046 - AcceptedFreezeException (Final) - this fixes a significant issue for s390x users and the fix is limited to s390-specific code so cannot affect primary arches
19:41:45 <cmurf> ack
19:41:46 <coremodule> Ack
19:41:47 <kparal> ack
19:41:51 <pschindl> ack
19:43:36 <adamw> #agreed 1335046 - AcceptedFreezeException (Final) - this fixes a significant issue for s390x users and the fix is limited to s390-specific code so cannot affect primary arches
19:43:44 <adamw> #topic (1390617) Pandaboard (omap4) fails to boot from mmc.
19:43:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1390617
19:43:44 <adamw> #info Proposed Freeze Exceptions, kernel, ON_QA
19:44:27 <cmurf> +1 FE
19:44:32 <cmurf> I mean if the kernel team is OK with it...
19:44:36 <kparal> +1
19:45:16 <jforbes> I think we are okay with both of the, 4.8.6 has the fix and is sitting in waiting for stable
19:46:01 <adamw> how much other change is there in 4.8.6?
19:46:07 <adamw> new kernel version at this point is...a bit late
19:46:21 <adamw> we've been slightly lax in requiring minimal change for fixes lately, but we should probably tighten up on it again
19:46:52 <jforbes> adamw: graphics fixes, a security update, the usual bits for a stable bump
19:47:05 <adamw> current stable kernel for f25 is kernel-4.8.4-301.fc25 , so taking 4.8.6 to fix this gives us two kernel version bumps
19:47:09 <adamw> i mean, it's the kernel, it's probably fine, but still
19:47:35 <adamw> hmm, there were a few CVEs in 4.8.5
19:47:38 <cmurf> well if the rec is to move to 4.8.6 for the GA kernel, I'd kinda rather see it happen this week than next week, or just hang out for 3 weeks..
19:48:05 <adamw> how about this - we can take it as an FE on principle, i'll chew over whether we really want to pull a new kernel version into final with jforbes outside of the meeting
19:48:08 <cmurf> haha oh wait, GA is next week!
19:48:15 <adamw> cmurf: go/no-go is thurdsay.
19:48:18 <jforbes> adamw: umm, 4.8.5 was the dirty cow CVE
19:48:42 <adamw> welp, we probably want that, then. :P
19:48:57 <sgallagh> That one probably should have had a blocker proposal.
19:49:06 <adamw> yeah.
19:49:11 <sgallagh> Don't we have a criterion for serious CVEs?
19:49:11 <jforbes> yeah, which is why I got it done before the freeze, but bodhi seemed to get stuck
19:49:13 <cmurf> kernel-4.8.6-300.fc25 is at +4
19:49:33 <adamw> final freeze was 2016-11-01 00:00 UTC, that kernel was submitted for stable on 2016-11-01 13:50 UTC
19:49:36 <adamw> so it just missed
19:49:43 * adamw goes to find his bureaucracy hat
19:50:05 <cmurf> kernel-4.8.6-201.fc24 is at +14
19:50:10 <sgallagh> jforbes: Where's the Fedora bug for that?
19:50:15 <cmurf> so overall 4.8.6 seems sane
19:50:17 <sgallagh> Let's just throw it on the blocker list
19:51:17 <cmurf> https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria#Security_bugs
19:51:31 <adamw> ok, proposed https://bugzilla.redhat.com/show_bug.cgi?id=1387080 as a blocker
19:51:42 <adamw> let's vote on this as an fe then vote on that as a blocker
19:51:47 <adamw> i'm +1 on this on principle
19:51:52 <adamw> cmurf and kparal, still +1?
19:51:57 <sgallagh> +1 FE
19:52:07 <cmurf> yes
19:52:20 <kparal> yep
19:52:35 <adamw> proposed #agreed 1390617 - AcceptedFreezeException (Final) - this is a significant issue on a supported ARM platform that cannot be fixed with an update, clearly worth a freeze exception
19:52:48 <adamw> grr, and now rhbz is being really slow for some reason
19:53:10 <adamw> hmm, wait
19:53:27 <adamw> jforbes: are you right about the cow? the bug report claims 4.8.3-300.fc25 fixed it
19:53:29 <cmurf> so is irc
19:54:11 <adamw> jforbes: the CVEs listed for 4.8.5-300 are CVE-2016-9083 , CVE-2016-9084 and CVE-2016-9083
19:54:24 <adamw> er, that one's so important i wrote it twice.
19:54:51 <jforbes> Oh right, sorry about that
19:55:01 <jforbes> So yeah, we are covered on that one
19:55:28 <adamw> how bad are 9083 and 9084?
19:55:42 <jforbes> not too bad
19:56:00 <adamw> both Moderate on access.redhat.com
19:56:09 <adamw> so, not blocker, but maybe FE-worthy in their own right
19:56:11 <jforbes> So basically the arm bugs are the issue for FE, otherewise, it is a 0 day update
19:56:30 <adamw> okay
19:56:55 <RaphGro> hi
19:56:57 <jforbes> I mean, it is fixed, and has karma, so the kernel is going out either way, just a matter of whether or not you care enough about those arm issues for installation
19:57:10 <RaphGro> is there any maximum of time slot for a meeting like that?
19:57:14 <adamw> jforbes: well, the risk is if that kernel somehow breaks something in install process. it's unlikely, but hey
19:57:20 <adamw> RaphGro: technically 3 hours.
19:57:30 <adamw> but we kinda need to get through this, we can't delay to next week at this point as there is no next week
19:57:41 <adamw> jforbes: i'll discuss with you in #fedora-kernel later, though, let's move on
19:57:47 <adamw> #agreed 1390617 - AcceptedFreezeException (Final) - this is a significant issue on a supported ARM platform that cannot be fixed with an update, clearly worth a freeze exception
19:57:58 <adamw> #topic (1390937) mem region issue with aarch64 NUMA host (and potentially other devices)
19:57:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1390937
19:57:59 <adamw> #info Proposed Freeze Exceptions, kernel, ON_QA
19:58:07 <adamw> this one's fixed by the 4.8.6-300 kernel build also
19:58:34 <sgallagh> Conditionally approve it if the other one goes through?
19:59:09 <adamw> "hosts are crashing during install" sounds FEish.
19:59:24 <adamw> so, I'm +1
19:59:29 <adamw> sgallagh: we just approved the other one...
20:00:28 <kparal> +1
20:00:55 <sgallagh> adamw: Sorry, I thought that was still conditional on whether the other CVEs were worthwhile
20:01:02 <sgallagh> In that case +1
20:01:32 <adamw> sgallagh: we gave it a freeze exception. we still have to decide whether we actually pull the fix, or ask for a smaller fix, or whate.
20:01:49 <adamw> but i wanna get through these bugs so i can go take a shower and have some lunch...
20:02:21 <sgallagh> I said +1
20:02:26 <adamw> right, juts noting.
20:02:50 <adamw> proposed #agreed 1390937 - AcceptedFreezeException (Final) - installer crashing on non-primary arch is a clear justification for a freeze exception
20:03:45 <sgallagh> ack
20:03:57 <kparal> ack
20:04:24 <adamw> #agreed 1390937 - AcceptedFreezeException (Final) - installer crashing on non-primary arch is a clear justification for a freeze exception
20:04:28 <adamw> #topic (1385836) [abrt] LabPlot: QApplication::notify(): labplot2 killed by SIGSEGV
20:04:28 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1385836
20:04:28 <adamw> #info Proposed Freeze Exceptions, LabPlot, ON_QA
20:05:13 <adamw> it's part of electronics lab, apparently
20:05:20 <adamw> are we shipping that for f25? dgilmore?
20:07:48 <adamw> oh, it's also in astronomy-kde
20:07:56 <kparal> I don't see it in http://dl.fedoraproject.org/pub/fedora/linux/development/25/Spins/x86_64/iso/
20:07:57 <adamw> and we *are* shipping that, i think. so +1
20:08:03 <adamw> kparal: it'd be in labs, not spins
20:08:07 <adamw> it's not there, but astronomy is.
20:08:17 <kparal> I don't see Labs
20:08:20 <adamw> ah, you're on dl
20:08:23 <adamw> then you need to look in alt
20:08:48 <adamw> hum. i don't see 25 in alt either
20:08:51 <adamw> what the frick ever
20:08:55 <adamw> https://kojipkgs.fedoraproject.org/compose/branched/Fedora-25-20161107.n.0/compose/Labs/x86_64/iso/
20:09:05 <kparal> ok
20:09:08 <dgilmore> adamw: let me look at the configs
20:09:13 <sgallagh> both are listed there for Beta
20:09:22 <adamw> anyhow, yeah, seems +1.
20:09:32 <kparal> +1
20:10:56 <adamw> proposed #agreed 1385836 - AcceptedFreezeException (Final) - this is a crasher bug in a default application on non-blocking media (Astronomy and Electronics Lab), so that qualifies it as a freeze exception issue
20:11:05 <kparal> ack
20:11:19 <garretraziel> ack
20:11:20 <sgallagh> ack
20:11:26 * adamw rushes because he's gotta leave in 19 minutes
20:11:26 <adamw> #agreed 1385836 - AcceptedFreezeException (Final) - this is a crasher bug in a default application on non-blocking media (Astronomy and Electronics Lab), so that qualifies it as a freeze exception issue
20:11:28 <satellit> ack
20:11:31 <adamw> #topic (1392203) mariadb permissions don't allow access to /var/lib/mysql
20:11:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1392203
20:11:31 <adamw> #info Proposed Freeze Exceptions, mariadb, NEW
20:11:38 <adamw> this one isn't fixed yet but looks really bad, so let's vote on it
20:11:43 <adamw> mariadb not starting ootb = bad
20:12:06 <adamw> so, definite +1 for me
20:12:26 <kparal> nothing depends on it by default?
20:12:34 <cmurf> what's in 19 minutes
20:12:37 <kparal> +1
20:12:37 <adamw> don't think so
20:12:42 <cmurf> +1 FE
20:12:42 <adamw> cmurf: lunch
20:12:44 <dgilmore> +1 FE
20:12:44 <adamw> cmurf: more importantly, lunch with my mother in law
20:12:52 <cmurf> wow
20:12:56 <sgallagh> +1
20:13:02 <adamw> kparal: we have a Server role for pgsql, so that's a blocker, but not for mariadb
20:13:21 <cmurf> don't ever be late for those
20:13:24 <adamw> proposed #agreed 1392203 - AcceptedFreezeException (Final) - mariadb is obviously a major component for many Fedora installs and should definitely work out of the box
20:13:38 <garretraziel> ack
20:13:43 <cmurf> ack
20:13:54 <cmurf> crack the whip!
20:14:02 <adamw> #agreed 1392203 - AcceptedFreezeException (Final) - mariadb is obviously a major component for many Fedora installs and should definitely work out of the box
20:14:11 <adamw> 3 more
20:14:12 <adamw> #topic (1391183) [abrt] mediawriter: pushbuf_kref(): mediawriter killed by SIGSEGV
20:14:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1391183
20:14:12 <adamw> #info Proposed Freeze Exceptions, mediawriter, POST
20:14:38 <cmurf> +1 it's in POST
20:14:41 <adamw> definitely +1
20:14:59 <adamw> might even be blocker, but definite +1 FE
20:15:02 <kparal> +1
20:15:06 <garretraziel> +1
20:15:14 <cmurf> yeah was going to ask, crashes for mediawriter may be blocking
20:15:17 <kparal> well it's not on any medium
20:15:26 <kparal> so we don't actually need FE
20:15:28 <adamw> proposed #agreed 1391183 - AcceptedFreezeException (Final) - mediawriter is the primary USB writing tool for F25, so obviously we should avoid known crasher bugs in it
20:15:35 <adamw> kparal: i think KDE might include it
20:15:36 <adamw> but anyhow
20:15:39 <adamw> let's get through this
20:15:43 <kparal> doesn't harm anything, +1
20:15:56 <adamw> ack/nack/patch ?
20:15:59 <kparal> ack
20:16:08 <garretraziel> ack
20:16:13 <adamw> #topic (1391212) Service fails if no switchable graphics present
20:16:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1391212
20:16:13 <adamw> #info Proposed Freeze Exceptions, switcheroo-control, ON_QA
20:16:15 <adamw> grrr
20:16:17 <adamw> #undo
20:16:17 <zodbot> Removing item from minutes: INFO by adamw at 20:16:13 : Proposed Freeze Exceptions, switcheroo-control, ON_QA
20:16:18 <adamw> #undo
20:16:18 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x3002f350>
20:16:25 <adamw> #undo
20:16:25 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x242f3610>
20:16:30 <garretraziel> hah
20:16:33 <adamw> #agreed 1391183 - AcceptedFreezeException (Final) - mediawriter is the primary USB writing tool for F25, so obviously we should avoid known crasher bugs in it
20:16:36 <cmurf> ack
20:16:43 <adamw> #topic (1391212) Service fails if no switchable graphics present
20:16:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1391212
20:16:43 <adamw> #info Proposed Freeze Exceptions, switcheroo-control, ON_QA
20:17:01 <cmurf> +1
20:17:02 <adamw> +1 to this, obviously, people hate failing services
20:17:13 <garretraziel> +1
20:17:17 <cmurf> i don't know why they're so picky
20:17:21 <kparal> +1
20:17:26 <adamw> heh
20:17:53 <adamw> proposed #agreed 1391212 - AcceptedFreezeException (Final) - avoiding failed services on every live boot and initial install is clearly worth doing
20:18:01 <cmurf> ack
20:18:04 <kparal> ack
20:18:09 <cmurf> what's this scopeo one? did that get skipped?
20:18:12 <adamw> #agreed 1391212 - AcceptedFreezeException (Final) - avoiding failed services on every live boot and initial install is clearly worth doing
20:18:17 <adamw> cmurf: it's the least important so i put it last
20:18:23 <cmurf> oic
20:18:25 <adamw> #topic (1391932) [skopeo][ FTBFS due golang deficiency on ppc64
20:18:25 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1391932
20:18:26 <adamw> #info Proposed Freeze Exceptions, skopeo, ON_QA
20:18:28 <adamw> there ya go
20:18:42 <adamw> okay, sure, fixing FTBFS is fine if it doesn't affect the media
20:18:44 <adamw> don't think this does
20:18:55 <cmurf> right
20:18:57 <kparal> I love the new and improved speed of these meetings. we should all have lunches with mothers in law :)
20:18:58 <cmurf> +1
20:19:05 <cmurf> haha
20:19:09 <adamw> nothin skopeo-related is in kickstarts or comps
20:19:11 <adamw> kparal: :P
20:19:20 <adamw> so, +1 then, can't hurt.
20:19:22 <kparal> +1
20:19:56 <cmurf> kparal: for you it'd be dinner
20:20:06 <kparal> I had dinner 3 hours ago
20:20:12 <cmurf> see!
20:20:19 <adamw> hum
20:20:21 <adamw> actually
20:20:23 <adamw> i'm changing to -1
20:20:26 <cmurf> coulda been a 20 minute meeting
20:20:30 <adamw> cos this looks a bit weird, and docker depends on skopeo
20:20:36 <cmurf> oh dang adamw decided to actually READ the bug
20:20:49 <kparal> that slows down the process, never do that
20:20:49 <adamw> there's no f25 update submitted, and the last f25 build had no ppc64 packages, and the referenced f24 build doesn't have any ppc64 packages either
20:20:57 <adamw> so i dunno what this is all about, but i'm not feeling +1y any more
20:21:05 <kparal> ok
20:21:08 <cmurf> why does this say 24
20:22:09 <sgallagh> Not fixing this will prevent PPC64 from launching the same day as primary, won't it?
20:22:30 <adamw> okay
20:22:30 <adamw> how about we punt and ask for details in-bug?
20:22:30 <cmurf> guess the same problem is happening on 24 and 25
20:22:31 <cmurf> yes
20:22:38 <cmurf> exactly
20:22:39 <sgallagh> agreed
20:22:52 <cmurf> maintainers didn't ask for FE
20:22:53 <adamw> proposed #agreed 13191932 - punt (delay decision) - this seems potentially worth fixing, but the current builds look a bit off, so we are going to ask for some details in the bug before deciding on this
20:23:17 <cmurf> good catch
20:23:20 <cmurf> ack
20:23:47 <adamw> ack/nack/patch?
20:23:49 <pschindl> ack
20:24:26 <cmurf> adamw: order something gin at lunch, then ask MiL whether to make it a tall
20:24:40 <adamw> #agreed 13191932 - punt (delay decision) - this seems potentially worth fixing, but the current builds look a bit off, so we are going to ask for some details in the bug before deciding on this
20:24:44 <adamw> (you had your chance)
20:24:48 <adamw> #topic Open floor
20:24:54 <adamw> alright, any other business while i take a very short shower
20:24:58 <cmurf> adamw has turned into the Flash
20:25:01 <kparal> ack
20:25:13 <kparal> nope
20:25:54 <cmurf> nope
20:27:48 <garretraziel> none
20:30:04 <adamw> thanks folks!
20:30:06 <adamw> #endmeeting