17:01:59 #startmeeting F25-blocker-review 17:02:00 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:02:00 The meeting name has been set to 'f25-blocker-review' 17:02:00 #meetingname F25-blocker-review 17:02:00 #topic Roll Call 17:02:00 The meeting name has been set to 'f25-blocker-review' 17:02:10 morning folks! who's around to review some blockers? 17:02:12 * kparal is here 17:02:13 .hello sgallagh 17:02:14 sgallagh: sgallagh 'Stephen Gallagher' 17:02:16 * pschindl is here 17:02:18 .hello jkurik 17:02:19 jkurik: jkurik 'Jan Kurik' 17:02:39 * coremodule is here. 17:02:46 * satellit listening 17:03:00 * garretraziel is lurking around, preparing lunch 17:03:35 .hello jforbes 17:03:36 jforbes: jforbes 'Justin M. Forbes' 17:04:16 morning morning 17:04:23 .chair jkurik sgallagh 17:04:26 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 heh 17:05:39 zodbot is in a good mood today 17:05:47 ....man, i think i need to go back to bed and redo this morning 17:05:51 #chair jkurik sgallagh 17:05:51 Current chairs: adamw jkurik sgallagh 17:06:00 let's try that again with the RIGHT cryptic sigil 17:06:23 adamw, tomrrow will be worse 17:07:00 maybe next time i'll try /chair and see what happens 17:08:14 #topic Introduction 17:08:14 Why are we here? 17:08:14 #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 #info We'll be following the process outlined at: 17:08:16 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:08:16 #info The bugs up for review today are available at: 17:08:18 #link http://qa.fedoraproject.org/blockerbugs/current 17:08:20 #info The criteria for release blocking bugs can be found at: 17:08:21 #link https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria 17:08:23 #link https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria 17:08:27 #link https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria 17:08:29 we have: 17:08:31 #info 7 Proposed Blockers 17:08:33 #info 3 Accepted Blockers 17:08:35 #info 10 Proposed Freeze Exceptions 17:08:37 #info 8 Accepted Freeze Exceptions 17:08:50 who wants to be that most-prized of all jobs, the secretary? 17:09:16 adamw, I will do it! 17:09:45 #info coremodule will be the great and powerful secretary 17:09:59 alrighty, so starting in with the proposed blockers 17:10:01 morning kevin 17:10:06 #topic (1370073) [abrt] gnome-shell: _g_log_abort(): gnome-shell killed by SIGTRAP 17:10:06 #link https://bugzilla.redhat.com/show_bug.cgi?id=1370073 17:10:06 #info Proposed Blocker, gnome-shell, NEW 17:10:18 halfline: around, by any chance? get any further with this one yet? 17:10:38 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 this kills whole session, right? 17:12:01 yes 17:12:37 Have we seen this in the wild outside of OpenQA? 17:12:48 pschindl has, according to the bug 17:12:49 NM 17:12:53 I didn't 17:13:09 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 ah 17:13:24 the key thing is that, we *think*, it's related to first login 17:13:25 so the theory about clean installs might be right 17:13:29 either g-i-s or something else that happens on first login 17:13:42 which would obviously explain why none of us sees it on day-to-day use systems 17:13:55 and it somewhat sucks to crash on first login 17:13:59 i checked all the openQA cases i could find and they were all on first login 17:14:00 Has anyone seen it happen within a live session? 17:14:09 It didn't happen immediately. I worked for a while. 17:14:10 sgallagh: don't think we've had that, no, it's really first login *after install* 17:14:15 pschindl: hmm, that's interesting 17:14:15 hmm 17:14:38 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 That doesn't seem to set a good first impression 17:14:59 It happened after I downoaded some file in firefox and I tried to close firefox 17:15:10 /me goes to do a clean install on a spare laptop 17:15:24 Do we want to investigate this a bit and loop back around to it? 17:15:24 in openQA this happens something like...i'd say 10% of the time 17:15:36 (i'd have to go crunch some numbers to give a really accurate one, that's a ballpark) 17:15:43 That's not small number. 17:15:46 sgallagh: you mean, within the meeting? 17:15:50 yes 17:16:07 mmm, sure. but i dunno how much investigation we'll get done 17:16:10 OK 17:16:33 I'm wondering how likely it is to hit on real hardware 17:16:40 fair enough 17:16:49 if it's 10% and really hard to solve, I'd be OK with not blocking. 17:16:56 But 10% in openQA is concerning 17:17:01 but I wouldn't argue against blocking either 17:18:11 yeah, it's definitely a 'last blocker smell test' kind of an issue 17:18:25 especially since it doesn't look like it's a trivial fix (on friday it had both halfline and mclasen stumped) 17:18:55 well, we can circle back to it, i guess 17:19:04 /me is pulling the latest nightly to test with 17:19:07 #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 zoiks, something weird happened to today's openqa workstation live run... 17:20:45 adamw: weirder than usual? 17:20:50 heh 17:20:56 looks like more asset cleanup shenanigans 17:21:02 anyhow. next bug 17:21:10 #topic (1390610) LibreOffice Impress crashes when you move slide pane into a separate window on Wayland 17:21:10 #link https://bugzilla.redhat.com/show_bug.cgi?id=1390610 17:21:10 #info Proposed Blocker, libreoffice, VERIFIED 17:21:31 shenanigans 17:22:17 this might be a bit controversial 17:22:28 I'm kind of 0 on blocker status, but I'm fine with +1 FE 17:22:34 however, if we just agree on +1FE and push it, we don't need to argue about a blocker 17:22:37 :) 17:22:42 -1 blocker +1 fe 17:22:45 +1 FE 17:23:17 +1 FE, -1 blocker 17:23:33 -1 blocker +1 fe 17:23:33 for the record, I'm inclined to +1 blocker 17:23:38 -1 blocker, +1 fe 17:23:42 FE for sure, i'm about a 0 on blocker. 17:23:47 kparal: why? 17:23:50 it is a crash, which is bad 17:24:00 because it's not just a crash. it makes OO unusable 17:24:01 true 17:24:10 but there's a fix to avoid the crash 17:24:19 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 yeah, I rember now, you cannot open LO anymore, can you 17:24:34 yeah it's not pretty 17:24:36 yeah 17:24:42 I don't think anybody knows the right shortcut, and removing all your configuration files is... ugly 17:24:57 garretraziel: you can open it, but you can no longer touch the floating pane 17:25:00 if it were X, I'd say block 17:25:10 so even if it is floating in the middle of the screen, you can move it away 17:25:23 kparal: Can you boot to X to fix it? 17:25:33 sgallagh: yes, that should work 17:25:44 but again, it's non-obvious 17:25:50 kparal: I'd be okay with that as a workaround in Common Bugs 17:26:04 it's a non-issue anyway, as long as we give it +1 FE 17:26:14 /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 it's been fixed 17:26:19 just like owies when ripping off bandaides - but moom it hurts! why?! it HURTS! MOM!!!!! 17:26:53 shhh honey here's another bandaid 17:27:00 Is there anyone here who *doesn't* think it deserves at least FE? 17:27:38 only if the fix ends up worse than the described current behavior... 17:28:05 Doesn't everyone just use Google Docs now anyway? 17:28:05 /me runs 17:28:32 I will give it FE to push the fix into the next compose and move on 17:28:46 Google annoyed me with their late and tepid support of ODF 17:29:55 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 ack 17:30:03 ack 17:30:15 ack 17:30:17 ack 17:30:51 ack 17:31:17 it's a trap! he said in lieu of ack! 17:32:31 ack 17:32:37 #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 #topic (1390607) LibreOffice Impress (and stripped down native gtk demo) doesn't run presentation correctly on Wayland 17:32:47 #link https://bugzilla.redhat.com/show_bug.cgi?id=1390607 17:32:47 #info Proposed Blocker, mutter, NEW 17:33:00 this is not a duplicate 17:33:17 is libreoffice-impress in the workstation live? 17:33:47 dgilmore: Yes 17:33:56 (I just confirmed that) 17:34:05 Yes, it appears in GNOME as "LibreOffice I..." 17:34:16 I found a workaround in c11. not sure it will work every time 17:34:16 okay 17:34:21 versus "LibreOffice..." and "LibreOffice C..." 17:34:33 cmurf: that sounds useful 17:34:37 cmurf: Depends on your screen resolution, I think. Mine gets all the way to Impr... 17:34:41 and "LibreOffice D..." 17:34:42 :D 17:34:45 yeah, i get 'Impr" 17:35:09 well i have the funky medium res screen but with big text enabled 17:35:12 Considering the huge amount of empty space between icons, you'd think it could just wrap... 17:35:32 irrelevant though 17:35:47 This sounds like pretty much the whole point of Impress isn't working under Wayland, though 17:36:01 yup 17:36:02 /me wonders why no one spotted this sooner... 17:36:35 so I'd say it's tentatively a blocker, and Workstation WG needs to decide what to do 17:36:36 because noone gave presentation on wayland yet 17:36:45 until Jiri Eischmann this weekend :) 17:37:00 a.) ship it broken, b.) fix it c.) yank it 17:37:14 I don't think tentatively at all. This is +1 blocker under the basic functionality criterion 17:37:45 yeah well, I'm cutting Wayland a lot of slack 17:37:52 So that leaves B) or C) there. 17:38:12 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 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 Wayland is the default environment in F25, so I'm giving it more weight than in previous releases 17:38:44 it sounds like the fix should not be hard 17:38:49 (Much too late to change our minds on that) 17:39:18 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 anyway +1 blocker 17:39:24 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 i think i'm a weak +1 blocker on this. 17:39:49 sgallagh: I would guess no one tried 17:39:52 I'm also weak +1 17:40:12 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 floating point blocker values 17:40:14 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 I am +1 blocker also 17:40:33 rtcm: thanks for the update 17:40:51 +1 17:41:03 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 ack 17:41:15 ack 17:41:18 ack 17:41:19 actually, patch 17:41:21 cmurf: "it's 0.867 blocker" 17:41:25 sgallagh: drop the extra ", i know 17:41:26 awesome sauce 17:41:26 ack 17:41:26 ack 17:41:32 adamw: No, other patch 17:41:37 go for it 17:41:42 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 But hey I'm in California which is sorta like a different country. 17:43:04 OK, I can't find a good way to note that the Wayland aspect is important. 17:43:12 So I'll just ack 17:43:33 supplementary comment? 17:44:25 Probably not important if a fix is impending anyway 17:45:08 #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 #topic (1389130) Existing RAID or LVM metadata can cause various types of install failures. 17:45:17 #link https://bugzilla.redhat.com/show_bug.cgi?id=1389130 17:45:17 #info Proposed Blocker, python-blivet, POST 17:45:45 Didn't we have this one last release too? 17:46:22 we always have raid bugs 17:46:25 It does sound familiar. 17:47:07 I'm laughing at this bug... 17:47:19 in a manaical way of course. 17:48:06 where is the nominating criterion? 17:48:48 OK comment 11 17:48:55 it was just set as blocking by upstream 17:49:16 i guess the obvious criterion is the catch all one... 17:49:54 sgallagh: #c10: "I think this has been fixed at least once before." 17:50:34 i think i'm +1 to this, though i wish we'd started working on it two weeks ago. 17:51:04 I want to be -1 17:51:38 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 I don't get a sense of how likely it is that a user would hit this 17:51:42 that's clearly a blocker to my mind. 17:51:47 ah, ok 17:51:52 In that case yes. +1 blocker 17:51:53 sgallagh: this is all based on reports from an actual user in IRC last week, so, very likely. :P 17:52:03 I am +1 to block. As we already have a patch, lets hope it is fixed prior the final compose 17:52:32 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 +1 blocker 17:53:28 cmurf: it's libblockdev changes, i think. 17:53:42 cmurf: Or more likely, people running RAID tend not to do overwriting updates on prereleases? 17:53:53 At least as a demographic 17:53:58 there's always an easy fix for application crashes or misbehaviors under wayland: run them under xwayland 17:54:17 mclasen_: is LO wayland-native? 17:54:25 i thought it was already running in xwayland... 17:54:30 yeah I just want custom partitioning gone, it's an out of scope conversation 17:54:37 I assumed so, otherwise why would it have wayland-specific crashes ? 17:54:41 i understand it's a blocker, by the book 17:54:51 mclasen_: eh, i dunno. we're past that bug now anyhow 17:54:58 adamw: it's native 17:55:05 so we have about +3 now 17:55:05 kparal: ah k 17:55:05 * mclasen_ shuts up 17:55:13 mclasen_: :P sorry, just trying not to get crosswise 17:55:35 any other votes? 17:56:06 I'm +1 too 17:58:18 alright, that seems like enough 17:58:33 +1 17:59:47 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 ack 18:00:28 ack 18:00:49 ack 18:00:52 ack 18:00:55 #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 #topic (1390027) Anaconda should tell the user it is running fsck, possibly allow to skip 18:01:53 #link https://bugzilla.redhat.com/show_bug.cgi?id=1390027 18:01:53 #info Proposed Blocker, python-blivet, NEW 18:01:56 so...this. 18:02:11 * cmurf snickers at adamw 18:02:37 was it possible to skip fsck in the previous releases ? 18:02:42 no 18:02:44 now I finally know why is anaconda so slow 18:02:47 yes 18:02:54 was fsck run even in previous releases? 18:02:54 I agree with comment 3 18:02:56 this has been kind-of-ongoing for a few releases now 18:03:03 +1 blocker, get rid of it 18:03:24 kparal: yes, i'm trying to dig up when this became an issue exactly, but it's not just 25 18:03:31 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 When does the fsck occur? 18:03:51 there is no good reason to force running fsck 18:04:06 always on every attached ext34 volume 18:04:13 is there any way to avoid 7.5 hour long fsck for large filesystems? 18:04:20 so, https://bugzilla.redhat.com/show_bug.cgi?id=1170803 was one of the previous bugs 18:04:21 if you have a 20TB ext4 volume, it will do a 3 day fsck 18:04:35 fun 18:04:36 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 this is another one where i wish someone would've proposed it three weeks ago... 18:05:15 I think it meets the criterion 18:05:17 the F21 bug claims to be fixed 18:05:36 kparal: It notes that it may have been reintroduced when blivet was split out 18:05:46 and it was rejected as a blocker in the past 18:05:50 "Disks not selected as installation targets must not be affected by the installation process in any way. " 18:05:57 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 Is it doing auto-repair? 18:06:18 If not, then fsck isn't actually "affecting" the FS 18:06:28 ah right, my corner cases 18:07:04 * kparal proudly shows off the note 18:07:24 A 20 minute read only fsck is still affecting those targets - the entire system is hung up while the fsck happens... 18:07:38 But I'm pretty sure this is a preen. 18:08:23 cmurf: I would assume that the term "affect" really should have been "alter" 18:08:50 yeah, that's what it means. 18:08:58 Preen will alter 18:09:02 * adamw pokes through blivet code 18:09:32 There's no reason to do this so indiscriminately. 18:09:41 If the file system were that busted it wouldn't even mount. 18:10:28 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 cmurf: I don't disagree with fixing this. I disagree with the lack of a fix blocking the release. 18:10:42 any call to update_size_info() will run a fsck, if it's possible for that filesystem. 18:11:40 There is a fix, Eric Sandeen removed the fsck requirement from ext3/4 resizes two years ago. 18:12:24 Actually the fsck requirement to poll for minimum resize size. 18:12:41 The fsck itself still gets done prior to the resize on a specifically chosen ext3/4 file system. 18:13:01 But the user hasn't asked for a resize on anything - and yet the fsck is still being done. 18:13:19 cmurf: yes, i am reading through that at present to see if it's all entirely true. 18:14:09 lack of faith disturbing 18:14:36 /me Force-chokes cmurf 18:15:19 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 I can reinstall and try again, I guess. 18:19:06 so 18:20:17 -1, sorry, too close to release, maybe next time? 18:20:29 yeesh, give a guy a chance to research heah 18:22:52 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 -p is preen which is automatically fix 18:23:14 -f is force, even if the fs is marked clean 18:24:11 yes, that's true., 18:24:29 i'm currently looking into two things: 18:24:35 1) how this behaved between f22 and f 24 18:24:46 2) whether it would actually be safe to remove the call for what blivet needs to do 18:25:46 it runs this on the live media image 18:25:58 it's wholly indiscriminate 18:27:56 i've never not seen e2fsck run on the live rootfs image, or any overlay derivative 18:29:13 can't parse that last one. 18:30:01 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 cmurf: okay. we know this was happening before f22. 18:31:09 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 hmm 18:31:35 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 Well the resize2fs change didn't also cause blivet to stop calling for e2fsck. 18:31:48 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 That's right, the requirement was removed. But blivet itself never changed. 18:32:24 tracing the code through blivet/anaconda history is tricky, but i don't think it ever got changed. 18:32:48 so, that would mean this has been happening for every release since F21. 18:33:14 Right it's not a new problem. It's not a regression. 18:33:24 Which leads me further down the path of: "It sucks, but let's not block on it" 18:33:33 which is kinda what dlehman's saying. 18:33:51 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 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 Add it to the new future priority fixes pile? 18:35:31 For the record, I'm also -1 FE as I'm concerned that poking around here will introduce other issues. 18:36:28 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 cmurf: +1 to adding it to the priority fixes pile 18:37:47 so.....i'm about 97% sure that it'd be safe to fix this. 18:37:51 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 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 that is no longer the case and we should change it, but it was not 'nonsense'. 18:39:10 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 (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 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 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 And yes trying to force preen a read only file system? Kinda very much nonsense. 18:40:18 anyhow 18:41:20 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 so just move on. 18:41:31 punt or whatever 18:42:10 cmurf: I don't think this would survive a Go/No-Go meeting. 18:42:17 Given that it's been this way for years 18:42:43 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 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 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 ack 18:45:23 ack 18:45:29 It would be nice if the fact that it is doing that was in the release notes or common bugs. 18:46:03 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 yeah, commonbugs would be good. 18:46:34 cmurf: changing that is about as disruptive as trying to fix it, really. 18:46:40 it's never good to try and wedge in new UI at the last minute. 18:47:29 It wasn't a feature proposal. 18:47:52 ack 18:48:30 ack 18:49:32 adamw: I'm not sure why you closed it as dupe, but did not reopen the other bug 18:50:06 we need at least one of them open 18:50:21 #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 kparal: i'm re-opening the other bug now 18:50:29 with a comment explaining why 18:50:30 ok 18:50:35 gimme a break here, lot of balls in the air 18:50:36 please slap commonbugs on it 18:50:48 #topic (1350054) Refuses to let systemd fix label of /dev/shm/lldpad.state on boot 18:50:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=1350054 18:50:48 #info Proposed Blocker, selinux-policy, ON_QA 18:50:53 you talk about that while i work :P 18:51:34 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 this is just in journal, no notification about it, right? 18:53:22 I don't remember seeing any notification 18:53:29 kparal: It shows up on the screen before dracut takes over 18:53:36 right 18:53:38 But I haven't seen it turn up as a GNOME notification 18:53:44 flashes through 18:54:13 It also didn't appear on boot of the live image I just started 18:54:17 I'm not that concerned about an error that just flashes through 18:54:27 I have intermittantly seen it cause GNOME sealert notifications 18:54:27 Not sure if that means the pending update was already included. 18:54:30