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