17:01:06 #startmeeting F20-blocker-review 17:01:06 Meeting started Wed Nov 27 17:01:06 2013 UTC. The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:06 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:24 #meetingname F20-blocker-review-3 17:01:24 The meeting name has been set to 'f20-blocker-review-3' 17:01:38 #topic Roll Call 17:01:51 #chair kparal adamw 17:01:51 Current chairs: adamw kparal roshi 17:01:55 * kparal sits 17:01:55 * roshi is here 17:01:58 * pschindl is here 17:01:59 ahoyhoy 17:02:02 * satellit listening 17:02:53 #topic Introduction 17:02:53 Why are we here? 17:02:53 #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:02:54 #info We'll be following the process outlined at: 17:02:54 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:02:54 #info The bugs up for review today are available at: 17:02:54 #link http://qa.fedoraproject.org/blockerbugs/current 17:02:55 #info The criteria for release blocking bugs can be found at: 17:02:55 #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria 17:02:56 #link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria 17:02:56 #link https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria 17:03:36 Up for discussion we have: 17:03:44 #info 10 Proposed Blockers 17:03:44 #info 14 Accepted Blockers 17:03:44 #info 12 Proposed Freeze Exceptions 17:03:44 #info 7 Accepted Freeze Exceptions 17:04:27 if there's no issues - onto the proposed blockers 17:04:42 #topic (1032620) Doesn't remember POP password 17:04:42 #link https://bugzilla.redhat.com/show_bug.cgi?id=1032620 17:04:42 #info Proposed Blocker, evolution, ASSIGNED 17:05:14 do we have a secretary? 17:05:28 i can do it 17:05:29 not I 17:05:49 thanks adamw 17:05:51 * nirik is lurking around, can try and pay attention today. 17:06:19 i'm inclined to -1 here. no-one else seems to be having troubles. i've tested this a few times in the course of desktop validation. 17:07:00 I've had no issues with keyring keeping passwords 17:07:01 -1 blocker. It seems to work in general, and this is just a concrete bug for a particular person 17:07:12 -1 due to few people hitting it 17:07:56 -1 17:08:15 * pwhalen is here 17:08:16 -1 17:08:53 could it be related to the issue that got mentioned on qa this morning? 17:09:02 which one? 17:09:12 https://bugzilla.redhat.com/show_bug.cgi?id=1032531 17:10:22 well it's probably unrelated -1 based on to few 17:10:37 proposed #agreed - 1032620 RejectedBlocker - While this is an issue, there doesn't seem to be enough people affected in order to be considered a blocker for Final Release. 17:10:45 ack 17:10:46 doesn't seem related 17:10:50 yeah, i'd guess not 17:10:52 ack 17:10:53 ack 17:10:54 ack 17:10:54 -1/ack 17:10:59 #agreed - 1032620 RejectedBlocker - While this is an issue, there doesn't seem to be enough people affected in order to be considered a blocker for Final Release. 17:11:12 #topic (960381) gnome-shell eats a lot of mem 17:11:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=960381 17:11:13 #info Proposed Blocker, gnome-shell, NEW 17:11:32 -1 17:11:51 same as previous bug - not many people running gnome that run into this 17:11:59 no movement, -1 unless it turns out to affect a lot of people 17:12:13 i did do the 'run all the apps' validation test yesterday and noticed Shell was up to 700MB at the end of it 17:12:23 so i'm sure there _are_ some leaks in there, but...doesn't seem terrible enough to block release over 17:12:30 I've experienced "freezes" and sluggish behavior but I blame thunderbird ;) 17:12:36 -1 at this point 17:12:38 and 500k emails 17:12:57 so -1 we can always revisit 17:12:57 -1 17:13:18 -1 17:13:29 proposed #agreed - 960381 RejectedBlocker - While this is an issue, there doesn't seem to be enough people affected in order to be considered a blocker for Final Release. If reproduction steps are found, please re-propose. 17:13:44 ack 17:13:48 ack 17:13:51 ack 17:13:51 ack 17:14:00 #agreed - 960381 RejectedBlocker - While this is an issue, there doesn't seem to be enough people affected in order to be considered a blocker for Final Release. If reproduction steps are found, please re-propose. 17:14:01 ack 17:14:14 #topic (969524) plasma widgets unclickable on arm 17:14:15 #link https://bugzilla.redhat.com/show_bug.cgi?id=969524 17:14:15 #info Proposed Blocker, kdelibs, NEW 17:15:12 the kde folks were going to look at this, but not sure they've made any progress 17:15:20 is KDE blocking? 17:15:25 yes 17:15:26 for arm it is 17:15:53 the KDE folks are probably busy testing the sddm -> kdm switch 17:15:57 +1 blocker 17:16:12 * kparal is not happy about arm blockers 17:16:25 +1 17:16:28 KDE is a blocking desktop for both arm and x86 17:16:28 yeah, +1 blocker based on what we know... 17:16:34 but this bug only affects arm 17:16:36 anyhow, obvious +1 17:16:43 +1 17:17:31 roshi: i already tested sddm to kdm, works fine. i know the KDE team is looking at this one. 17:17:42 +1 17:17:47 proposed #agreed - 969524 AcceptedBlocker - This bug clearly violates the default panel functionality release criteria: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use. " 17:18:01 ack 17:18:05 ah - wasn't sure, just knew it was happening 17:18:05 ack 17:18:16 ack 17:18:40 #agreed - 969524 AcceptedBlocker - This bug clearly violates the default panel functionality release criteria: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use. " 17:18:52 #topic (1004621) plasma-nm doesn't attempt to connect to any listed networks on Fedora KDE live 17:18:53 #link https://bugzilla.redhat.com/show_bug.cgi?id=1004621 17:18:53 #info Proposed Blocker, kde-plasma-nm, ON_QA 17:19:41 adamw did you find anything new? 17:20:06 oh, this is one reason for the SDDM -> KDM switch 17:20:11 works fine with KDM, in my test image anyhow 17:20:34 so a vote is academic at this point for blocker status? 17:21:06 is KDM the default as of TC3? 17:21:33 no, it'll be TC4 17:21:37 ok 17:21:39 it was a comps change, din't make TC3 17:21:41 * roshi didn't think so 17:21:51 +1 blocker 17:22:48 +1 17:23:00 +1 17:23:13 +1 17:23:16 +1 17:23:29 sure, +1 17:23:59 +1 17:24:19 * roshi finds relevant criteria 17:25:53 panel functionality, i guess 17:25:57 https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_panel_functionality 17:26:44 proposed #agreed - 1004621 AcceptedBlocker - This bug violates the Final release criteria Default Ppanel Functionality: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use. " 17:27:02 ack 17:27:02 * roshi was going to do go with app functionality - but panel is a better fit 17:27:09 ack 17:27:10 ack 17:27:33 ack 17:27:41 #agreed - 1004621 AcceptedBlocker - This bug violates the Final release criteria Default Panel Functionality: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use. " 17:28:09 #topic (1034701) When installing F20 from PXE, after clicking on disk management, GUI is horribly lagging and 'loop1' process consumes 100% of CPU 17:28:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=1034701 17:28:09 #info Proposed Blocker, kernel, NEW 17:28:48 anyone else seen this when doing a PXE install? 17:29:04 no 17:29:10 and I doubt that it's related to PXE 17:29:15 probably to disk contents 17:29:16 * roshi hasn't tried PXE install before 17:29:17 I have not, done quite a few 17:30:04 I noticed last night there were no loop devices, was unable to mount an iso, use kpartx 17:30:36 -1 since the reporter can't reproduce 17:30:48 no, i asked him if he can reproduce *without PXE* 17:31:03 there's no indication that he can't reproduce even with PXE (though we should probably ask) 17:31:06 but he used TC3, and the original report is probably on TC2 17:31:12 I was just going to say that was assuming his first statement was with PXE 17:31:19 oh that's a point 17:31:25 i was assuming it was without, but it's unclear 17:31:29 anyhow, i'm punt or -1 17:31:34 -1 for now 17:31:35 it read to me that he tried to repro with TC3 17:31:36 I'm -1 17:31:58 -1. if this is confirmed by anaconda or affecting more people, we can re-evaluate 17:32:07 I've done many PXE installs, never saw this one 17:32:22 I doubt it has anything to do with PXE, rather previous VM contents 17:32:37 -1, didnt see it myself, wait for more info 17:33:11 proposed #agreed - 1034701 RejectedBlocker - This bug does not seem to be reproducible or affect a large set of users so is not considered a Final Blocker. If reproduction steps can be found, please re-propose. 17:33:23 ack 17:33:28 ack 17:33:33 ack 17:33:53 #agreed - 1034701 RejectedBlocker - This bug does not seem to be reproducible or affect a large set of users so is not considered a Final Blocker. If reproduction steps can be found, please re-propose. 17:34:02 #topic (1035000) SELinux issue when dealing with big_key support 17:34:02 #link https://bugzilla.redhat.com/show_bug.cgi?id=1035000 17:34:02 #info Proposed Blocker, kernel, NEW 17:35:05 +1 17:35:44 sounds serious 17:35:48 +1 17:35:56 +1 17:36:00 wait this seems to be able to be fixable via update 17:36:04 -1 +FE 17:36:18 hard to block on the kernel 17:36:38 Viking-Ice, where do you see fixable via update? 17:36:51 * roshi doesn't know where to look 17:36:51 roshi, it's freeipa 17:36:52 I suppose it could be... as long as people can login to apply the update. 17:36:53 it's not fixable with an update for live desktop though 17:37:01 Viking-Ice: it's auth against a remote server (freeipa or AD) 17:37:02 most probably can be fixed by update, and doesn't affect LiveCDs 17:37:04 point cmurf 17:37:06 how serious is having AD? 17:37:14 for people who auth using AD, quite serious :) 17:37:17 not having 17:37:22 however, we should still consider whether we want to have it working on release day 17:37:28 does our criteria cover remote auth 17:37:37 right, what's the criteria? 17:37:38 does this affect also graphical logins? 17:37:40 and how many people running AD we have on live CD and that could not be fixed by update for rest? 17:37:41 Viking-Ice: it'd be a conditional violation of the user creation or boot-to-working-desktop criteria 17:37:53 jreznik: it's not about live CD 17:37:59 jreznik: it's about first boot, basically 17:38:11 you can configure remote auth as part of initial setup if you're using GNOME 17:38:13 adamw: live cd was that question for fixability with update 17:38:17 no, it isn't 17:38:18 this is 17:38:28 so this is selinux rather than kernel? 17:38:31 so you can make it to GDM without having a local user account 17:38:41 cmurf: yes 17:38:51 and if you can't log in with that remote account, you're kinda locked out. except, i don't think you could do that without having a local root 17:38:53 ok so this might be fixable with a policy change 17:38:56 it seems misassigned to me 17:38:57 so i don't think you're ever _really_ locked out 17:39:03 if that's the case, i'd be a +1 17:39:14 it's quite a close call, but probably -1 / +1 for me 17:39:20 dwalsh 17:39:39 it's not misassigned 17:39:42 you have to read the original bug 17:39:46 i don't see him around 17:39:52 selinux issues are outblocker right so 17:40:06 Viking-Ice: sorry? 17:40:14 autoblocker I mean 17:40:14 adamw: except it's private. 17:40:19 * nirik looks with another account. 17:40:20 i didn't mean that one 17:40:24 yeah it's private i can't see the original bug 17:40:28 there's actually a nother long report for this 17:40:34 i assumed that was it, but it's not. let me dig it out 17:40:48 adamw, selinux issues for all the bits we shipped 17:40:58 on live/dvd 17:41:18 how about pinging jwb to look at it before voting? 17:41:19 anyhow, it's a avc, but not selinux policy? so, the kernel is doing something wrong as to where and what it's doing, and the policy is ok? 17:41:48 rare but possible 17:42:00 * nirik was asking adamw, since he seems to know the issue. ;) 17:42:02 damnit, can't find the bug 17:42:10 nirik: basically, yes, it's not practical to fix it with a policy change. 17:42:12 * kparal pinged sgallagh 17:42:15 * adamw trying to find the details from yesterday 17:42:20 kparal: You summoned me? 17:42:29 yes 17:42:41 ahhh 17:42:44 sgallagh: should the bug be fixed in the kernel or in selinux policy? 17:42:46 the explanation was all on IRC 17:42:55 kparal: in the kernel 17:43:06 is the fix ready? 17:43:07 Sorry, I meant to update the bug with the IRC discussion and didn't do so 17:43:09 mea culpa 17:43:21 Fix is identified and a patch exists. 17:43:28 It needs a review and a merge into the kernel 17:43:28 http://fpaste.org/57269/13855742/ is the IRC discussion from yesterday 17:43:44 sgallagh: can you install a machine with remote auth without having any local (root) account at all? 17:43:52 or is local root account always present? 17:44:26 kparal: root *account* is always present. 17:44:44 Accessible or not depends on whether it had a password set at installation 17:44:46 that fix is fixable via update right 17:45:00 hmm, it might not have a password set, that's probably right 17:45:01 anaconda won't let you out without *either* setting a root password *or* creating a local user account with admin privileges 17:45:12 (anaconda can't configure remote auth yet) 17:45:21 ok 17:45:43 ok, in that case some admin account is always present, even with remote auth configured 17:45:46 adamw: Even via kickstart? 17:45:58 sgallagh: i think even via kickstart, yeah. 17:46:03 imbw, but...meh. 17:46:11 if you're kickstartin' you can deal with this one way or another. 17:46:17 ok, then if that's the case, you should always have root access 17:46:17 yes, with kickstart it will stop at the menu 17:46:39 So yes, probably fixable in an update. 17:46:45 so yeah, i think i'm -1/+1, and if we land it as FE, do it soon 17:46:53 votes? 17:46:54 A bad first impression, but maybe not a blocker. 17:46:56 so, -1 blocker, +1 FE? although if we are going to take it as a FE we should do it...yeah, what adamw said 17:47:07 -1/+1 17:47:09 -1/+1 17:47:13 I was -1/+1 17:47:23 we should bring jwb/kernel folks into the loop too. 17:47:27 -1/+1 17:47:38 (not to spoil the party) 17:47:41 -1 blocker, how bad the kernel changes are? 17:47:49 jwb was pretty against it being a blocker, in the irc log. 17:48:42 jreznik: pretty small. 17:48:57 then I can be -1/+1 17:49:35 proposed #agreed - 1035000 RejectedBlocker - This bug doesn't clearly violate any criteria, and users can still log on to the machine. Accepted as a Freeze Exception. 17:49:46 patch 17:49:47 ack 17:50:04 proposed #agreed - 1035000 RejectedBlocker AcceptedFreezeException - This bug doesn't clearly violate any criteria, and users can still log on to the machine. Accepted as a Freeze Exception. 17:50:09 ack 17:50:11 ack 17:50:28 ack 17:50:39 #agreed - 1035000 RejectedBlocker AcceptedFreezeException - This bug doesn't clearly violate any criteria, and users can still log on to the machine. Accepted as a Freeze Exception. 17:50:54 #topic (1026283) Nautilus eating 100% cpu 17:50:54 #link https://bugzilla.redhat.com/show_bug.cgi?id=1026283 17:50:54 #info Proposed Blocker, nautilus, NEW 17:51:36 ok but is the UI still responsive? 17:52:16 I think you can't start a new nautilus window 17:52:27 and there is no visible window 17:52:30 pschindl: correct? 17:52:54 There is no visible window 17:53:06 this also seems to not affect too many folks... possibly only those with sqlite db's that tracker chokes on? 17:53:16 -1 - few people are running into this, and all you have to do is kill the process 17:53:29 with non-starting nautilus it is hard. Once I can open new window and next time when I encounter this bug I can't 17:53:45 also quite possibly fixable in updates... 17:53:59 I would think updates would fix it 17:54:02 there's another issue with sqlite which may be related 17:54:13 3 people see this, that's not that few 17:54:17 https://bugzilla.redhat.com/show_bug.cgi?id=1034714 17:54:24 I don't use tracker so I'm not affected 17:54:56 is the kernel locking? or just the database? 17:55:11 adamw: but that's a bug in sqlite, and the former one is bug in tracker, I think 17:55:18 at least the patch is against tracker 17:55:29 but due to sqlite bug, isn't it? 17:55:35 yeah, might not be related, just seemed interesting that two sqlite-related things showed up about the same time 17:55:38 but it would be good to test with the new sqlite to make sure. 17:55:56 * adamw asked desktop folks if they want to come by 17:55:58 yep 17:56:03 good 17:56:04 if it is a sqlite issue, should this be retested with TC3 that has the sqlite patch? 17:56:22 roshi: I'd say so yeah. 17:56:41 +1 punt for TC3 testing 17:56:42 pschindl uses updates-testing, so he should have all the updates 17:56:48 i'm leaning toward punt to give time to test the suggested patch 17:56:59 point kparal 17:57:00 mclasen: any opinion on this one? 17:57:02 kparal: but I don't update sqlite 17:57:11 counterpoint pschindl 17:57:12 pschindl: ok, now you should :) 17:57:14 but then punt always means having to re-read the bug in a week or two from scratch to refamiliarize ;-) 17:57:25 lol 17:57:37 I stopped when I was asked for testing older version 17:57:51 but I thing I can start to use the newest one again :) 17:57:53 votes on punt? 17:58:09 how about punt until desktop team shows up? 17:58:10 I thought it was 17:58:10 but I didn't get around to confirm with rishi 17:58:13 (related, that is) 17:58:18 i'm ok with punting 17:58:30 punt it 17:58:48 punt for now 17:59:11 the problem is that it happens only randomly 17:59:11 sure 17:59:17 punt 17:59:37 proposed #agreed - 1026283 Punt - This bug is potentially already fixed with the release of TC3. Will revisit next meeting. 18:00:02 it was accepted freeze exception 18:00:21 ack 18:00:33 ack 18:01:12 ack/nack/patch? 18:01:19 nack 18:01:25 mclasen: adamw: Regarding that Nautilus CPU thing. 18:01:25 It happened to me once yesterday with sqlite-3.8.0.2-4. 18:01:26 So it is not related to the sqlite-3.8.1 regression. 18:01:54 the plot thickens.... 18:02:10 I have met it with slite-3.8.0.2-4 too 18:02:40 the thlot chickens 18:03:05 the chicken thplots 18:03:08 ok, revote on blockeryness? 18:03:11 it's an evil genius chicken with a lisp 18:03:24 kinda hard to get a feel for how commonplace it's likely to be 18:03:30 sure it's not a genius chicken that's evil? 18:03:39 true 18:04:19 I'm back to my -1 vote since sqlite doesn't fix it 18:05:16 votes? 18:05:25 * roshi is thinking people are watching FESCO 18:06:08 * adamw was waiting on rishi 18:06:24 rishi: any thoughts on blocker status for this bug? any idea how common it's likely to be? 18:06:48 I hit it yesterday for the first time. 18:07:03 There is an upstream report with some more people: https://bugzilla.gnome.org/show_bug.cgi?id=710413 18:07:07 the consequence isn't really all _that_ terrible - can't run nautilus till you restart 18:07:14 So looks common enough. 18:07:22 the workaround is to disable search in gnome settings :) 18:07:50 the criterion cited is kind of for 100% failures - more like 'we're shipping a completely broken nautilus!' than 'some other bug can possibly cause nautilus to fail to start sometimes' 18:08:07 adamw: It's enough to kill the nautilus, then you can run new one 18:08:30 right, that too 18:08:43 so i guess i'm -1/+1 18:08:47 do we enable tracker on live? 18:08:48 -1 blocker/+1 FE 18:08:56 +1 FE 18:08:57 -1/+1 18:09:19 -1/+1 18:09:19 I don't thing that we should really block because of this bug. But I'd like to see this bug fixed - -1/+1 too 18:09:30 adamw: I think we do. Else gnome-documents won't work. 18:09:44 ok, so yeah, +1 fe 18:09:51 What is the absolute hard deadline to get this in the GA? 18:10:06 well, theoretically, one day before go/no-go 18:10:15 but really, we would probably not want to take a change like this that late 18:10:28 I can try poking at Tim's patches / analysis this week. 18:10:41 proposed #agreed - 1026283 RejectedBlocker AcceptedFreezeException - While this bug is annoying, there are easy workarounds available. A fix will be considered past freeze. 18:10:45 go/no-go is next thursday; i'd say we'd probably want this in by the end of this week if we're gonna take it 18:10:50 ack 18:10:51 ack 18:10:57 ack 18:11:00 ack 18:11:11 #agreed - 1026283 RejectedBlocker AcceptedFreezeException - While this bug is annoying, there are easy workarounds available. A fix will be considered past freeze. 18:11:33 #topic (1034714) Regression in 3.8.1 causes breakage in Tracker's SPARQL queries 18:11:34 #link https://bugzilla.redhat.com/show_bug.cgi?id=1034714 18:11:34 #info Proposed Blocker, sqlite, ON_QA 18:12:14 adversely affects functionality 18:12:35 oh it's basically an FE already by votes in comments 18:12:50 yeah 18:13:18 yeah, already acceptedfe, but it was proposed as a blocker too 18:13:39 the question is whether this is a basic app functionality 18:13:40 if the FE is there, do we need to vote blockeryness? 18:13:48 sure we do 18:14:17 _probably_ we can just push the fix as FE and close it out, but it's possible that the fix doesn't work - if the bug's only FE we can just back it out, if the bug's blocker, we have to fix it properly 18:14:43 ok, that makes sense 18:14:52 if it fundamentally breaks functionality of included gnome apps as described, sounds like a blocker though 18:14:53 adamw: In that we can back out the 3.8.1 package with an epoch. 18:15:01 *that case 18:15:51 I think this is not a fundamental functionality 18:15:57 it's kinda close 18:16:07 ok so step 1 is "install gnome-photos" 18:16:08 albums is fairly close to fundamental for a photo app 18:16:14 cmurf: it's there out of the box if you install from DVD 18:16:16 it's not included so that's not a blocker 18:16:21 it is, for a DVD / netinst 18:16:25 hmm 18:16:28 it's cut off the lives for space 18:16:35 got it 18:16:52 so in that case it hits the basic functionality part of the criteria it seems 18:17:28 if i were making a real operating system, i'd kinda want this to be a blocker. 18:17:32 but we're making fedora...:P 18:17:38 * adamw remembers back when he had standards 18:17:56 +1 blocker 18:18:16 adamw: somehow the proximity to the end of the year is what relaxes my standards 18:18:23 i think it's mostly the whisky 18:18:26 it's already being worked on - I don't see this as a high risk blocker 18:18:29 what the hell, let's pretend i'm young again 18:18:30 +1 blocker 18:18:33 LOL 18:18:43 drinking this early adamw? 18:18:49 * roshi should move to canada 18:18:58 roshi: what the hell do you think i put on my shreddies? 18:19:03 +1 18:19:23 shreddies? 18:19:28 breakfast cereal 18:19:37 i thought he was accusing me of being an alcoholic rather than it being the end of the year that relaxes me standards 18:19:38 what, america doesn't have shreddies? go join your friends in al qaeda 18:19:42 orange juice, but that might just be me 18:19:51 shreddies? 18:19:54 .fire roshi insufficient alcoholism 18:19:54 adamw fires roshi insufficient alcoholism 18:20:05 that's +3 blocker 18:20:08 yeah 18:20:24 +1 18:20:32 "performance evaluation: does not pull his weight in hard liquor consumption' 18:21:20 proposed #agreed - 1034714 AcceptedBlocker - This bug violates the Final criteria: "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." 18:21:35 ack 18:21:42 that's the first time I've heard of being fired for drinking too little 18:21:51 * roshi will work to remedy that :p 18:22:08 happens in Japan 18:22:18 boss says at 6pm "we're going drinking" 18:22:20 you do NOT say no 18:22:31 even if it's a Friday 18:22:36 and you have a date 18:22:44 mmmm, sake 18:22:46 that's ludicrous. you wouldn't have a date. 18:22:59 ack 18:22:59 yeah, this is the land of the neck-beard 18:23:06 ack/nack/patch? 18:23:10 ack 18:23:17 ack 18:23:23 #agreed - 1034714 AcceptedBlocker - This bug violates the Final criteria: "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." 18:23:44 #topic (1006386) Boot takes 27 seconds longer with /var/log/journal than without 18:23:44 #link https://bugzilla.redhat.com/show_bug.cgi?id=1006386 18:23:44 #info Proposed Blocker, systemd, NEW 18:23:55 oh dear this one 18:23:57 ah, the bug with the unfortunate title 18:24:19 i thought i'd changed that 18:24:23 obviously wasn't drinking enough 18:24:26 c54 is important 18:25:06 given the input from michal and lennart i'd go for +1 18:25:29 +1 18:25:35 +1 18:25:39 I'm totally +1. 18:25:41 preventing successful boot is bad, yo 18:25:42 +1 18:26:20 +1 18:26:31 ctrl-alt-del works on linux? 18:26:39 (why are not log writes asynchronous, anyways?) 18:26:48 cmurf: who knew, rite 18:27:00 what does it do? 18:27:10 cmurf: try that in console. we will see you later :) 18:27:18 +1 18:27:24 hMMM 18:27:27 * cmurf is curious now 18:27:31 alpha boot criteria for this one? 18:28:01 well how about that, the computer rebooted 18:28:07 so is this doing something like a reboot -f ? 18:28:30 intersting to see fesco is deciding for us the EOL process 18:29:10 proposed #agreed - 1006386 AcceptedBlocker - This bug violates the Beta release criteria: "A system installed without a graphical package set must boot to a working login prompt without any unintended user intervention, and all virtual consoles intended to provide a working login prompt must do so." 18:29:30 * roshi was tempted to use "preventing successful boot is bad, yo" as the justification 18:29:50 ack 18:31:00 ack 18:31:09 ack 18:31:16 adamw, pschindl? 18:31:23 cmurf 18:31:25 ack 18:31:34 #agreed - 1006386 AcceptedBlocker - This bug violates the Beta release criteria: "A system installed without a graphical package set must boot to a working login prompt without any unintended user intervention, and all virtual consoles intended to provide a working login prompt must do so." 18:31:52 #topic (1026860) Instantiated service is not run, it stays in inactive state (and systemd debug log does not state why) 18:31:52 #link https://bugzilla.redhat.com/show_bug.cgi?id=1026860 18:31:52 #info Proposed Blocker, systemd, NEW 18:32:26 roshi: sorry, got hung up on a discussion in #anaconda 18:32:34 roshi, adamw probably has passed out now during one of his Canadian bench drinking 18:32:40 oh no wait there he is 18:32:47 oh near god another lvm bug 18:32:53 I think we should reject this just based on bug report length 18:33:34 yeah it's longer then my entire biography could be 18:33:37 tl:dr? 18:33:58 comment 25 18:34:01 it's a bug at least 18:34:15 lvm on raid problem. however, it seems to occur only in certain configurations IIUIC 18:34:24 yep 18:34:35 and race 18:35:00 +1 18:35:36 so last week we asked: 18:35:42 "Peter, LVM devs - it'd help a lot if we could get some information / educated guesses on how common this issue is likely to be." 18:35:48 and no one replied to that 18:35:49 since then i see an awful lot of debugging, but no impact evaluation 18:35:52 so i'm still kinda clueless 18:36:20 yeah 18:36:31 We are now supporting LVM on md raid right? 18:36:42 still race on boot so it could hit many or none and you know Murphy strikes after we release GA 18:37:05 (I wish we'd move to integrated LVM raid if LVM is used at all, to eliminate a layer but whatever) 18:38:02 So if this always, or frequently impacts LVM on md RAID, then it seems more likely a blocker. 18:38:37 comment 8 says it's lvm on md, but doesn't say how common it is 18:38:49 oops i'm wrong, it says 50% of the time 18:38:55 I can confirm this bug exists. I thought it was my hardware, but now that I see the bugreport, that is almost what exactly is happening to me 3 out of every 4 boots. 18:39:13 you on raid 18:39:16 +1 blocker 18:39:32 yeah when this first popped up it was right after LVM thinp booting got fixed and there was a separate bug report indicating regression that I couldn't reproduce 18:39:37 danofsatx: can you describe your setup? 18:39:43 unintentionally - I wasn't paying attention when I set up the LVM and it spanned the drives, so it is seeing it as a RAID 18:40:07 LVM over several disks is not the same as LVM on RAID 18:40:08 128GB SSD, 1TB HD, LVM spanning both of them. 18:40:08 no, wait, we need to be precise. 18:40:23 sees devices as dm-# 18:40:56 that might be encryption 18:41:06 I think we should block on it ones they have figure out what the issue is we should revisit and see how wide impact it would be to implement it 18:41:16 it is encrypted. If this helps...... http://ur1.ca/g3vxg 18:41:23 danofsatx: 'lsblk | fpaste' 18:41:55 viking's approach sounds sensible to me 18:41:59 keep it on the radar 18:42:06 right 18:42:07 ok, lsblk looks much easier to read: http://ur1.ca/g3vxk 18:42:16 and have it accepted so if the fix shows up at any time and it's clear we should include it, there's no delay 18:42:21 so - blocker or punt to keep an eye on it? 18:42:40 yeah, no raid there... 18:42:40 +1 blocker for now 18:42:45 * roshi notes we don't always make it to reviewing accepted blockers and we have one more meeting before Go/No-Go 18:42:47 encrypted / lvm 18:42:53 danofsatx: no raid, but I have no idea why you have double encryption on each partition 18:42:54 +1 blocker for now as well 18:43:16 anaconda did it. I don't know why either. 18:43:35 that's a bug 18:43:40 i'd say that's a big bug 18:43:45 if you can try to reproduce that, file it 18:43:51 do we have a preferred criteria for this one? 18:43:52 yeah rather big bug 18:44:02 you've got a PV that's encrypted, and then each LV is encrypted 18:44:09 talk about performance murder 18:44:38 esp if the CPU doesn't have aes-ni 18:44:38 bigger faster better hw 18:44:53 roshi: initial boot behaviour i guess 18:45:08 alpha post-install? 18:45:10 yeah 18:45:15 if you hit this bug, your system doesn't boot 18:45:26 and note the preamble to that section about 'all configurations described above' 18:45:37 (i.e. any system installed in a way that's covered by the criteria should boot) 18:45:57 * roshi writes #agreed 18:47:48 danofsatx: this might be relevant https://bugzilla.redhat.com/show_bug.cgi?id=1030416 18:48:16 proposed #agreed - 1026860 AcceptedBlocker - This bug violates the alpha post installation criteria as well as conditionally violating additional initialization requirements: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or 18:48:16 a 'first boot' utility." 18:48:29 too long 18:48:40 proposed #agreed - 1026860 AcceptedBlocker - This bug violates the alpha post installation criteria as well as conditionally violating additional initialization requirements: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation..." 18:48:48 ack 18:48:52 ack 18:49:01 ack 18:49:17 ack 18:49:25 #agreed - 1026860 AcceptedBlocker - This bug violates the alpha post installation criteria as well as conditionally violating additional initialization requirements: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation..." 18:49:26 ack 18:49:40 that's all the proposed blockers 18:49:41 hey who cloned jreznik2 again 18:49:52 moving onto Proposed FE's 18:50:13 Viking-Ice: more jreznik more voting power 18:50:16 we have 12 of them :) 18:50:18 #topic (1033764) When rootfs is on btrfs subvolume, and extlinux is the bootloader, the system doesn't boot 18:50:18 #link https://bugzilla.redhat.com/show_bug.cgi?id=1033764 18:50:19 #info Proposed Freeze Exceptions, anaconda, NEW 18:50:37 -1, extlinux isn't supported. 18:50:40 jreznik is like voltron, the more you plug in the better it gets 18:50:54 -1 18:50:59 oh, we're onto FEs now? 18:51:01 sorry, missed that 18:51:05 could be a blocker 18:51:12 where did we end up with btrfs 18:51:23 tech preview, right? 18:51:26 Viking-Ice: extlinux is an explicitly unsupported hidden option for anaconda 18:51:29 so can't block anything 18:51:48 i guess i can go +1 FE as it looks like the fix is isolated to the extlinux code in anaconda (so can't break anything we care about)( 18:52:00 correct 18:52:12 so i'd be +1 if the fix only touches the code that only gets used when doing extlinux bootloader 18:52:20 yeah me to 18:52:21 +1 18:52:26 +1 FE 18:52:34 right and it's also the same code that applies rootflags= for rootfs on btrfs for grub2 18:52:37 it's just missing for extlinux 18:52:44 sounds pretty clean, then 18:52:58 and it may not even happen so... 18:53:27 proposed #agreed - 1033764 AcceptedFreezeException - A fix will be considered past freeze provided it does not adversely impact other aspects of the installer. 18:53:40 ack 18:53:42 ack 18:53:45 smacking an ack 18:53:51 #agreed - 1033764 AcceptedFreezeException - A fix will be considered past freeze provided it does not adversely impact other aspects of the installer. 18:54:05 #topic (1035316) anaconda should not write the vconsole.keymap=... boot option 18:54:05 #link https://bugzilla.redhat.com/show_bug.cgi?id=1035316 18:54:05 #info Proposed Freeze Exceptions, anaconda, POST 18:54:56 +1 18:55:10 +1 18:55:14 let's try to get this one fixed 18:55:18 +1 18:55:23 mike's test looked good, so i'm ok with +1 here 18:55:30 i will be testing too, since this is my pet area... 18:55:38 +1 18:55:39 you mean this is your AREA ;) 18:56:15 proposed #agreed - 1035316 AcceptedFreezeException - A fix will be considered past freeze. 18:56:22 ack 18:56:24 ack 18:56:47 ack 18:56:49 #agreed - 1035316 AcceptedFreezeException - A fix will be considered past freeze. 18:57:08 #topic (1031299) displays duplicate for each btrfs device with btrfs filesystem show 18:57:08 #link https://bugzilla.redhat.com/show_bug.cgi?id=1031299 18:57:08 #info Proposed Freeze Exceptions, btrfs-progs, MODIFIED 18:57:19 in the meantime can some people test booting without the vconsole option to make sure nothing boots 18:57:30 nothing breaks 18:57:33 if nothing boots, that's bad. :P 18:57:39 and yeah, that'd be a good test. 18:57:42 * roshi was wondering at that 18:57:47 it's found in /etc/default/grub, remove it from the cmdline_linux line, and then grub2-mkconfig -o blah blah blah 18:58:07 yes nothing BREAKS 18:58:15 * cmurf fires himself 18:58:16 nothing booting is too easy 18:58:17 or just hand edit grub2.cfg 18:58:23 grub2-mkconfig is for the WEAK 18:58:51 I thought you were supposed to memorize all the boot args and hand-type them each time 18:59:00 that's why I avoid rebooting 18:59:01 wtf are we skipping 3.12 now 18:59:02 :p 18:59:20 huh? 18:59:30 " 18:59:30 btrfs-progs 3.12 fixes this bug, but is intended for kernel 3.12 which isn't going to ship with F20." 18:59:32 no we're committed to releasing F20 on 3.11 but 3.12 appeared quite some time ago so it's not getting much attention 18:59:42 yeah now why is that 18:59:56 btrfs is doing it wrong. ;( 18:59:57 just nuke this bug, it doesn't matter 19:00:25 the current progs is fine, there's a work around, and all of this gets fixed post install with a 3.12 kernel and 3.12 progs 19:00:55 *blink* 19:00:58 i should have withdrawn the FE request myself 19:01:03 cmurf: what happens if you upgrade btrfs-progs and not the kernel? 19:01:08 oh, we changed bugs. 19:01:09 i don't know 19:01:15 it should be fine 19:01:21 if 3.12 is intended for kernel 3.12, why is it in repos now? http://ur1.ca/g3w0a 19:01:24 but it's an untested situation 19:01:35 I can pretty much tell you people will hit it. ;) 19:01:42 will hit what 19:02:04 safe approach would be -1, and the bug doesn't sound that terrible 19:02:10 upgrade btrfs-progs and the kernel and then 3.12 breaks their frobnoz device, so they boot the old kernel. 19:02:14 eric sandeen is unconcerned about 3.12 going in with a 3.11 kernel 19:02:18 so i'm -1 on principle, we can always reconsider if we need 3.12 to fix some more serious bug or something 19:02:30 ok, then cool. I was just responding to the 'meant for 3.12' thing 19:02:42 -1 19:02:48 http://imgflip.com/i/52jk0. 19:02:51 http://imgflip.com/i/52jk0 19:02:51 yeah that might be confusing 19:02:52 that seems to be questionable. cmurf, sandeen and dlehman all have slightly different takes on it. it's kind of a question of emphasis. but we don't hve to worry about it hugely. 19:03:13 Viking-Ice: no-one's skipping any kernel releases; just that f20 *GA* will have 3.11 not 3.12, 3.12 will be an update 19:03:50 3.12 needs love we probably should have pulled it in at beta 19:03:53 yeah i just was being a bit cautious on shipping 3.12 progs which *creates* file systems and fixes them, with a kernel that it wasn't explicitly intended for; it shouldn't break anything, it's just that maybe there's something the newer progs expects will be in only the newer kernel 19:04:29 proposed #agreed - 1031299 RejecteFreezeException - This bug doesn't seem to have a large impact on users and can be fixed via updates. 19:04:42 and also it's relatively untested combination 19:04:49 ack 19:04:54 ack 19:05:28 ack 19:05:31 ack 19:05:36 #agreed - 1031299 RejectedFreezeException - This bug doesn't seem to have a large impact on users and can be fixed via updates. 19:05:40 patch...yeah, that one 19:05:41 :P 19:05:43 belated ack 19:05:45 :) 19:06:07 #topic (1033250) The keyboard layout for the virtual console cannot be changed using “localectl set-keymap ; dracut -f; reboot;” 19:06:07 #link https://bugzilla.redhat.com/show_bug.cgi?id=1033250 19:06:07 #info Proposed Freeze Exceptions, dracut, NEW 19:06:07 sorry for that messiness 19:06:12 np 19:06:31 this was the reference in bug 1035316 19:06:50 yeah, we probably only need one to be FE. 19:06:58 i didn't think the new bug needed to be created at all, really 19:07:03 but meh 19:07:04 ok let's skip it 19:07:16 yeah, skip it, consider the nomination withdrawn/transferred to 1035316/whatever 19:07:50 kk 19:07:52 moving on 19:08:05 #topic (1035029) Reviewing installed updates does not work 19:08:05 #link https://bugzilla.redhat.com/show_bug.cgi?id=1035029 19:08:05 #info Proposed Freeze Exceptions, gnome-software, NEW 19:08:43 +1 19:09:17 be nice to have this fixed, and i've tested the update in a live image, works fine for package installation and removal and key approval and updates and all the rest of it. 19:09:23 so +1 19:09:29 +1 19:09:47 +1 19:09:58 +1 19:10:03 +1 19:10:25 proposed #agreed - 1035029 AcceptedFreezeException - A fix will be considered past freeze. 19:10:31 ack 19:10:56 ack 19:11:21 ack 19:11:30 #agreed - 1035029 AcceptedFreezeException - A fix will be considered past freeze. 19:11:55 #topic (1035066) Volume gets restored to 100% after each knotify event 19:11:55 #link https://bugzilla.redhat.com/show_bug.cgi?id=1035066 19:11:55 #info Proposed Freeze Exceptions, kde-runtime, MODIFIED 19:12:51 heh, that doesn't sound like fun 19:12:52 +1 19:12:55 +1 19:12:57 +1 19:13:02 +1 19:13:05 +1 19:13:08 +1 19:13:32 proposed #agreed - 1035066 AcceptedFreezeException - A fix will be considered past freeze. 19:13:39 ack 19:13:43 ack 19:13:47 ack 19:13:53 #agreed - 1035066 AcceptedFreezeException - A fix will be considered past freeze. 19:14:09 #topic (1032921) KDE f20 TC2 x86_64 fails to shutdown from menu bar 19:14:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=1032921 19:14:09 #info Proposed Freeze Exceptions, kde-workspace, NEW 19:14:54 +1 19:15:13 this bug is annoying, but it doesn't actually stop you from doing what you want 19:15:48 be interesting to see if KDM switch fixes itr 19:15:55 true 19:16:00 * roshi hadn't thought of that 19:16:21 +1 FE at least, this is close to blocker 19:16:39 yeah +1 19:16:40 https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Desktop_shutdown.2C_reboot.2C_logout 19:16:46 "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work. " 19:16:57 randomly not working 40% of the time is pretty close to violating that 19:17:04 well is this not a a clear blocker 19:17:06 then 19:17:10 yeah 19:17:21 #13 ""Confirmed this" simply means that I ran an installation of KDE to bare metal and the panel didn't work for shutting down - no pop up. " 19:17:23 i certainly wouldn't be -1 blocker 19:17:33 +1 blocker 19:17:49 but the next two installations I've done didn't hit that error 19:18:03 or at any point during testing Live KDE with TC2 19:18:14 I haven't seen it since 19:18:47 but it looks like other people are hitting it 19:18:48 it's one of those 'how often is this going to hit people' questions 19:18:50 pretty hard to call 19:19:00 * roshi hasn't in a while 19:19:01 yeah 19:19:11 it's a clear blocker if it's happening all the time 19:19:20 okay, i'm pretending to have standards today, so +1 blocker 19:19:37 willing to have my mind changed if someone can demonstrate convincingly that it's not too common 19:19:54 that'll only come with more tests 19:19:59 time will tell with TC3 19:20:15 +1 blocker 19:20:27 remember, still SDDM in TC3 19:20:30 TC4 will be KDM 19:21:21 proposed #agreed - 1032921 AcceptedBlocker - This bug violates the Beta Release criteria: "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work. " 19:21:23 right 19:21:24 ack 19:21:32 ack 19:21:35 but I haven't seen this with TC2 - so I wonder if I will with TC3 19:21:39 ack 19:21:46 #agreed - 1032921 AcceptedBlocker - This bug violates the Beta Release criteria: "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work. " 19:22:12 #topic (1022733) Kernel 3.11 hangs on boot with VIA Velocity network adapters 19:22:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=1022733 19:22:13 #info Proposed Freeze Exceptions, kernel, MODIFIED 19:23:07 +1 fe 19:23:36 +1 19:23:48 +1 19:23:59 +1 19:24:03 +1 we need to ensure the fix ends up in GA releases as well 19:24:22 proposed #agreed - 1022733 AcceptedFreezeException - A fix will be considered past freeze. 19:24:34 Viking-Ice: you want an action item for checking that? 19:26:20 adamw, kparal, nirik, Viking-Ice:ack/nack/patch? 19:26:27 jreznik2? 19:26:28 ack 19:26:50 ack 19:26:54 ack 19:27:04 #agreed - 1022733 AcceptedFreezeException - A fix will be considered past freeze. 19:27:27 #topic (1028063) Quicklauncher icons missing 19:27:28 #link https://bugzilla.redhat.com/show_bug.cgi?id=1028063 19:27:28 #info Proposed Freeze Exceptions, lxde-common, ON_QA 19:28:09 +1 19:28:12 +1 19:28:17 +1 19:28:20 +1 19:28:31 +1 19:28:42 proposed #agreed - 1028063 AcceptedFreezeException - A fix will be considered past freeze. 19:28:48 ack 19:28:49 ack 19:28:54 ack 19:28:54 ack 19:28:56 #agreed - 1028063 AcceptedFreezeException - A fix will be considered past freeze. 19:29:08 3 more to go 19:29:11 #topic (1035004) Quicklauncher icons missing 19:29:11 #link https://bugzilla.redhat.com/show_bug.cgi?id=1035004 19:29:11 #info Proposed Freeze Exceptions, lxpanel, ON_QA 19:29:58 sorry, got distracted 19:30:16 np 19:30:24 same bug? hum 19:30:30 yeah 19:30:45 #undo 19:30:45 Removing item from minutes: 19:30:46 no, they're different 19:30:49 I see yeah. 19:30:56 christoph explained 19:31:02 could probably still have done it under one bug report, but meh. 19:31:03 yep. +1 19:31:10 #info Proposed Freeze Exceptions, lxpanel, ON_QA 19:31:21 +1 19:31:24 +1 19:31:25 +1 19:31:32 +1 19:31:38 +1 19:31:43 proposed #agreed - 1035004 AcceptedFreezeException - A fix will be considered past freeze. 19:32:08 ack 19:32:09 ack 19:32:26 ack 19:32:30 #agreed - 1035004 AcceptedFreezeException - A fix will be considered past freeze. 19:32:44 #topic (862871) btrfs /etc/fstab entry, dump and fsck don't apply 19:32:44 #link https://bugzilla.redhat.com/show_bug.cgi?id=862871 19:32:44 #info Proposed Freeze Exceptions, python-blivet, ASSIGNED 19:33:32 how risky is this 19:33:54 * roshi has no idea 19:34:20 I wouldn't think much risk 19:34:22 +1 19:35:07 although btrfs could also 'fix' this the way that xfs is now... 19:35:08 _sounds_ safe... 19:35:13 eeeh, i guess I'm +1 before next week 19:35:18 ie, a fsck.btrfs that just does 'exit 0' 19:35:19 after that, n odice 19:35:26 if little risk, +1 19:35:33 +1 19:35:40 nirik: 'suuuuure, looks fine to me' 19:35:42 :P 19:36:02 * nirik sees adamw is all agreeable... quick, lets ask him for things. ;) 19:36:26 i was visualizing that kind of fsck as a person 19:36:36 proposed #agreed - 882871 AcceptedFreezeException - A fix will be considered past freeze. 19:36:37 some kinda dodgy engineer or something 19:36:50 ack 19:36:53 ack 19:36:54 ah, fair enough. 19:36:54 ack 19:37:02 #agreed - 882871 AcceptedFreezeException - A fix will be considered past freeze. 19:37:17 #topic (1031696) libvirt: machines get killed when scopes are destroyed 19:37:17 #link https://bugzilla.redhat.com/show_bug.cgi?id=1031696 19:37:17 #info Proposed Freeze Exceptions, systemd, NEW 19:38:14 is this not a blocker 19:38:28 well 19:38:42 potential dataloss on shutdown I guess? 19:38:59 _theoretically_ there's a data loss potential, but i'd really hope no-one would just blindly shut down a VM host on which a whole bunch of guests were running and trust they'd all get cleanly suspended without even testing it once 19:39:15 * nirik always manually stops them... but perhaps thats just me 19:39:15 i'd block a RHEV release for this, but fedora? eeeeeeh. 19:39:19 no, me too 19:39:22 you know if people can people will 19:39:29 indeed. 19:39:29 Viking-Ice: and those people deserve our scorn 19:39:32 :P 19:39:36 it doesn't seem that there is a fix yet. 19:39:41 * danofsatx feels scorned 19:39:53 I'd +1 FE this... but unless there's a simple fix very soon, too bad. 19:40:28 yeah, now compared to the previous issue, this is a textbook example of devs flailing around trying to find something that works 19:40:30 +1 FE if fix is found by next meeting? 19:40:32 which doesn't make me especially confident 19:40:56 hm I'm not so sure we want to be pulling in a fix in systemd this late 19:40:59 -1 19:41:01 right 19:41:40 * Viking-Ice goes on another nicotine/coffee hunt 19:41:40 i'm +1 on the severity, but i'm worried that they don't seem to be projecting an air of confidence in the fix... 19:41:43 yeah, we can always approve it as FE and then say the fix it too much 19:41:58 i think i'd suggest we punt 19:42:09 works for me 19:42:09 say we're open to the possibility of fixing it, but we're worried about the potential impact 19:42:11 +1 punt 19:42:28 we'd like to see a fairly focused fix and devs who sound convincing when they say 'we're sure this is going to work and not break anything else' 19:42:52 sure, wfm 19:43:36 so that's +3 punt and viking went for a ssmoke break 19:43:40 proposed #agreed - 1031696 Punt - A fix would be considered past freeze if the fix is focused and won't break anything else. Punting for more information regarding potential fixes. 19:43:46 * roshi was writing 19:44:29 ack 19:44:40 ack 19:44:47 ack 19:45:09 #agreed - 1031696 Punt - A fix would be considered past freeze if the fix is focused and won't break anything else. Punting for more information regarding potential fixes. 19:45:25 that's all the proposed FE's 19:45:30 hurray 19:45:36 do we want to move onto Accepted Blockers? 19:45:40 or call it a day? 19:47:33 i have a new proposed FE 19:47:33 https://bugzilla.redhat.com/show_bug.cgi?id=1035423 19:47:39 was proposed earlier in the meeting 19:47:54 ok 19:48:06 there's also https://bugzilla.redhat.com/show_bug.cgi?id=990910 19:49:09 so let's cover those two 19:49:25 #topic (1035423) Use after free causes critical warnings in g-s-d, potential crasher 19:49:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=1035423 19:49:25 #info Proposed Freeze Exceptions, glib2, MODIFIED 19:51:02 it's easy to vote for or against. crasher, but nobody hits it and it's a prominent component 19:51:53 I could go either way with this one - if they bug has been there for 2 years... 19:52:28 well, i think it may have only been made possible to hit by the change we took to fix session switching 19:52:41 er, fix cursor stuff, rather 19:52:58 I don't read it that way, but I don't mind +1 19:53:00 +1 since it's low risk 19:53:13 sure, +1 19:53:31 proposed #agreed - 1035423 AcceptedFreezeException - A fix will be considered past freeze. 19:53:41 kparal: adamw is correct, the fix for the cursor bug triggers this glib bug 19:54:26 rtcm_: so, what does 'potentially a crasher' mean precisely? 19:54:28 * Viking-Ice catches up 19:54:34 what has to change before this actually crashes anything? 19:54:42 * adamw is not sure how theoretical the possibility is 19:54:58 adamw: my current best guess is compiler flags, but I'm not entirely sure 19:55:22 it seems that the way it gets built on fedora, doesn't trigger a crash 19:55:25 for the first we arent going to be defining a release criteria for cloud init that said +1 19:55:31 i'd be inclined to -1 unless we can actually demonstrate that it may cause people using fedora 20 to crash 19:55:41 Viking-Ice: let's deal with that one when we get to it 19:56:10 ack/nack/patch? 19:56:32 oh, we're acking now? well, okay. 19:56:36 adamw: it is a genuine use after free bug, like valgrind notices it for instance 19:56:41 are we acking both 19:56:43 or what ? 19:56:50 Viking-Ice: no? we haven't done 990910 at all yet 19:56:52 Viking-Ice: the one in title 19:56:53 sigh 19:56:57 ack 19:57:03 oky, fine, ack 19:57:04 *topic 19:57:06 if it explodes don't blame me 19:57:09 we can always revote 19:57:20 ack 19:57:33 #agreed - 1035423 AcceptedFreezeException - A fix will be considered past freeze. 19:57:46 #topic (990910) SELinux blocks cloud-init from installing/updating RPMs with scripts. 19:57:46 #link https://bugzilla.redhat.com/show_bug.cgi?id=990910 19:57:46 #info Proposed Freeze Exceptions, selinux-policy, NEW 19:58:20 +1 FE for sure 19:58:26 +1 FE 19:58:30 blocker would be an...interesting discussion, but it's nearly time, so let's just call it FE 19:58:36 +1 19:58:48 +1 19:58:56 proposed #agreed - 990910 AcceptedFreezeException - A fix will be considered past freeze. 19:59:08 ack 19:59:34 ack 19:59:54 ack 19:59:56 #agreed - 990910 AcceptedFreezeException - A fix will be considered past freeze. 20:00:07 well, it's time - we did 10 Blockers and 14 FEs 20:00:10 not bad, IMO 20:00:19 anything else? 20:00:36 I think QA should start brewing mead 20:00:44 works for me 20:00:52 * roshi already has all the gear for that :) 20:01:13 ;) 20:01:22 adamw, kparal - either of you have any more bugs we need to go over? 20:01:38 god forbid :) 20:01:41 * roshi lights fuse 20:02:03 3 20:02:42 2 20:03:09 nope 20:03:16 40 seconds is an awfully long 3-2-1 countdown 20:03:20 1 20:03:23 * adamw votes for scrumpy 20:03:43 thanks for coming all! 20:03:45 #endmeeting