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