16:04:23 <roshi> #startmeeting F21-blocker-review
16:04:23 <zodbot> Meeting started Wed Oct 15 16:04:23 2014 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:04:23 <roshi> #meetingname F21-blocker-review
16:04:23 <zodbot> The meeting name has been set to 'f21-blocker-review'
16:04:24 <roshi> #topic Roll Call
16:04:29 <roshi> who's around?
16:05:00 * jreznik is around but again, running the other meeting :(
16:05:15 * roshi is here
16:05:22 <roshi> no worries jreznik :)
16:05:30 * pwhalen is here
16:05:40 <roshi> #chair pwhalen kparal adamw tflink
16:05:40 <zodbot> Current chairs: adamw kparal pwhalen roshi tflink
16:06:38 <roshi> since I know adamw and kparal are here
16:06:39 <adamw> ahoyhoy
16:06:55 * adamw is absolutely not tinkering with relval in the other window
16:07:51 <adamw> kalev wanted to drop by and talk about getting GNOME 3.14.1 a freeze exception later
16:08:00 <adamw> he'll be here in ~20mins
16:08:19 <roshi> sounds good
16:08:33 <roshi> onto: The Boilerplate
16:08:34 * kparal is here
16:08:37 <roshi> #topic Introduction
16:08:37 <roshi> Why are we here?
16:08:37 <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.
16:08:40 <roshi> #info We'll be following the process outlined at:
16:08:43 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:08:46 <roshi> #info The bugs up for review today are available at:
16:08:48 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:08:51 <roshi> #info The criteria for release blocking bugs can be found at:
16:08:53 <roshi> #link https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria
16:08:56 <roshi> #link https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria
16:09:06 <roshi> welcome kparal :)
16:09:13 <roshi> we've got three proposed
16:09:17 <roshi> first up
16:09:24 <roshi> #topic (1145783) F21 install crashes on Intel firmware RAID with "AttributeError: 'NoneType' object has no attribute 'startswith'"
16:09:27 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1145783
16:09:30 <roshi> #info Proposed Blocker, python-blivet, MODIFIED
16:10:40 <adamw> this one's fairly slam-dunk-y
16:10:49 <adamw> should be fixed in TC3, I believe, but there's another one right behind it
16:11:36 <roshi> seems a blocker to me
16:11:38 <adamw> i hit this doing my firmware RAID testing on...I don't remember, TC2?
16:12:11 * satellit joining late
16:12:22 <roshi> welcome satellit
16:12:32 <roshi> +1 from me
16:13:11 <kparal> +1
16:13:16 <adamw> hi satellit
16:13:21 <adamw> +1 of course
16:13:59 <jskladan> +1
16:14:06 <pwhalen> +1
16:14:10 <roshi> proposed #agreed - 1145783 - AcceptedBlocker - This bug is a clear violation of the Beta criteria: "The installer must be able to detect and install to hardware or firmware RAID storage devices."
16:14:24 <kparal> ack
16:14:28 * mattdm is here
16:14:33 * mattdm is sort of here, really
16:14:50 <roshi> welcome mattdm (whatever percentage of you is here :p )
16:15:08 <jskladan> ack
16:15:17 <adamw> ack
16:15:19 <roshi> #agreed - 1145783 - AcceptedBlocker - This bug is a clear violation of the Beta criteria: "The installer must be able to detect and install to hardware or firmware RAID storage devices."
16:15:25 <adamw> oh, who's secretarying? I can if needed
16:15:29 <roshi> I'll do the split from this one next
16:15:30 <pwhalen> ack
16:15:33 <adamw> ahoy mattdm section #1
16:15:37 <roshi> thanks adamw
16:15:49 <roshi> #topic (1150147) Parent of existing mdcontainer does not have mdmember format - "ValueError: member has wrong format" on Intel firmware RAID install of F21
16:15:52 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1150147
16:15:54 <roshi> #info Proposed Blocker, python-blivet, MODIFIED
16:16:16 <adamw> aaaand this is the othe rone
16:16:20 <adamw> will be fixed in TC4/RC1
16:16:32 <roshi> +1 for same reason
16:16:37 <adamw> yup
16:16:46 <kparal> +1
16:17:23 <roshi> proposed #agreed - 1150147 - AcceptedBlocker - This bug is a clear violation of the Beta criteria: "The installer must be able to detect and install to hardware or firmware RAID storage devices."
16:17:26 <pwhalen> +1
16:17:30 <roshi> whee for recycling!
16:17:51 <jskladan> ack
16:18:13 <adamw> ack
16:18:25 <kparal> ack
16:18:39 <roshi> #agreed - 1150147 - AcceptedBlocker - This bug is a clear violation of the Beta criteria: "The installer must be able to detect and install to hardware or firmware RAID storage devices."
16:18:54 <roshi> last proposed
16:18:55 <roshi> #topic (1148923) ValueError: this device's formatting cannot be modified
16:18:58 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1148923
16:19:01 <roshi> #info Proposed Blocker, python-blivet, MODIFIED
16:19:46 * adamw reads
16:20:49 <roshi> seems a non-gui install is failing for this
16:20:53 <adamw> yeah, 'text'
16:20:53 <roshi> no criteria listed in the bug
16:21:08 <adamw> not sure if it's kickstart-driven text only, or also manual would hit it
16:21:12 <adamw> shouldn't be too hard to try though
16:21:16 <roshi> yeah
16:21:34 * roshi tests now with a text install
16:22:13 <adamw> well, maybe you need some other factor to hit it too
16:22:49 <pwhalen> ive done text installs, kickstarts on arm with no issue
16:23:07 <kparal> "Apparently the gui code that intends to hide them isn't running during automated installations."
16:23:11 <kparal> seem automated only?
16:24:15 <adamw> well, i wasn't quite sure if that maybe should have said 'text' not 'automated'
16:24:27 <adamw> but yeah, a manual text install doesn't seem to hit it
16:24:35 <adamw> so if i was being a stickler i'd probably say -1/+1 for this
16:25:20 <roshi> text install is working for me now
16:25:53 <roshi> violates unattended installation - if it's reproducible
16:26:07 <roshi> but I don't see any repro steps in the bug at first glance
16:26:34 <kparal> "Any installation method or process designed to run unattended must do so."
16:26:46 <adamw> oh, i was figuring it wouldn't happen if you did a GUI unattended install
16:26:48 <adamw> but maybe i'm wrong
16:27:11 <adamw> i'm +1 if we assume this applies to all automated installs, let's see if dlehman can clarify
16:28:12 <roshi> sgtm
16:28:51 <pwhalen> ive done 4 ks installs today, havent hit it
16:29:50 <adamw> there've been a couple of bugs involving whatever the hell it is they're doing with this 'zram' thing
16:29:53 <adamw> we probably should understand that
16:30:33 <adamw> proposal: throw a +1 FE at it for now and it'll probably go away
16:31:02 <roshi> works for me
16:31:06 <roshi> +1 adamw
16:31:52 <pwhalen> +1 fe
16:32:50 <roshi> proposed #agreed - 1148923 - RejectedBlocker AcceptedFreezeException - It's not clear how widespread this is or how to reproduce it so rejecting it as a blocker. Accepted as a Freeze Exception.
16:33:19 <pwhalen> ack
16:33:58 <adamw> nack
16:34:08 <adamw> i was meaning, make it AcceptedFE and leave blocker undetermined, don't reject it
16:34:12 <adamw> we're punting on blocker
16:34:28 <roshi> ah
16:34:34 <roshi> I'll patch it
16:36:24 <roshi> proposed #agreed - 1148923 - Punt AcceptedFreezeException - It's not clear how widespread this is or how to reproduce it so waiting to determine blocker status. Accepted as a Freeze Exception.
16:36:54 <adamw> ack
16:36:59 <roshi> hey kushal :)
16:37:10 <jskladan> ack
16:37:17 <roshi> here's some background on these meetings in case you're not familiar: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting#In_Action
16:37:32 <roshi> s/#In_Action//
16:37:45 <roshi> #agreed - 1148923 - Punt AcceptedFreezeException - It's not clear how widespread this is or how to reproduce it so waiting to determine blocker status. Accepted as a Freeze Exception.
16:37:58 <roshi> onto FEs - we've got 4
16:38:04 <roshi> proposed, that is
16:38:20 <kushal> roshi, Thanks.
16:38:34 * roshi couldn't remember if you'd ever been to one before
16:38:39 <roshi> np
16:38:55 <roshi> alright FE time
16:38:56 <roshi> #topic (1141549) ABRT cannot report any detected kernel oops
16:38:56 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1141549
16:38:56 <roshi> #info Proposed Freeze Exceptions, abrt, MODIFIED
16:40:34 <kalev> it's on the live media and affects bug reporting there
16:41:05 <adamw> oh, yeah, i've seen this
16:41:14 <adamw> +1, we should fix it, though reporting kernel oopses manually isn't too hard
16:41:27 <roshi> yeah
16:41:29 <kalev> +1 from me as well
16:41:30 <roshi> +1
16:41:56 <kparal> +1
16:41:59 <jskladan> +1
16:42:39 <roshi> proposed #agreed - 1141549 - AcceptedFreezeException - While manually reporting a kernel oops isn't terribly difficult it would be good to get this fixed.
16:42:39 <pwhalen> +1
16:42:45 <adamw> ack
16:43:00 <kalev> ack
16:43:34 <kparal> ack
16:43:35 <roshi> #agreed - 1141549 - AcceptedFreezeException - While manually reporting a kernel oops isn't terribly difficult it would be good to get this fixed.
16:43:45 <roshi> #topic (1103496) boot.iso 20140601 configuration screen is blank
16:43:45 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1103496
16:43:45 <roshi> #info Proposed Freeze Exceptions, anaconda, NEW
16:44:54 <adamw> oh, this one's back?
16:45:06 * satellit I have not seen this lately
16:45:33 <kparal> that seems like the KDE bug
16:45:38 <kparal> 'screen stuck' bug
16:45:38 <satellit> did workstation netinstall with workstation last night
16:45:53 <adamw> yeah
16:46:02 <adamw> so the *earlier* report is for boot.iso
16:46:03 <roshi> are we shipping a boot.iso?
16:46:07 <adamw> but the *recent* one is for kde live
16:46:12 <roshi> ah
16:46:14 <adamw> roshi: well, it's the same thing as the server/ws netinsts, really
16:46:25 <adamw> so i'd say satellit's recent report of this is a dupe of #1142862
16:46:28 <kparal> all of that seems to be under VirtualBox though?
16:46:33 <adamw> we should probably have #1142862 in the proposed FEs, though...
16:46:45 <roshi> true - but if they worked and boot.iso didn't in some magical land - I don't think we'd block on it since it's not a Product
16:46:47 <adamw> kparal: have you seen that one lately?
16:47:00 <kparal> I haven't run KDE since then
16:47:08 <kparal> outside of KDE, no
16:47:24 <satellit> KDE and mate lives installed ok for testing
16:48:20 <pwhalen> seeing similar redraw issues on arm netinstalls, package install doesnt progress unless you move to a spoke (useradd or root pass), come back to the main screen and it shows a change. but it remains frozen again until completed
16:49:02 <adamw> hmm
16:49:03 <pwhalen> reboot button appears, but the progress bar remains incomplete
16:49:05 <roshi> +1 if it's on our lives
16:49:18 <adamw> it's odd that we seem to be getting reports mostly with KDE now, but pwhalen sees it on netinst...
16:50:01 <adamw> i'm sort of feeling +1-y in general but very unclear on the specifics and how this and 1142862 differ / don't differ
16:51:51 <pwhalen> i posted a screen in the other bug for reference - https://bugzilla.redhat.com/show_bug.cgi?id=1142862
16:52:23 <kalev> if it turns out to be a bug in the installer -- do we have to accept it as a freeze exception before the anaconda team looks into it?
16:52:41 <adamw> no, it only has to be FE for the fix to go through freeze
16:52:44 <roshi> +1 from me
16:53:23 <adamw> pwhalen: so for you it was just stuck in that state - the progress bar not moving?
16:53:50 <pwhalen> right, stays stuck unless you move to one of the config spokes, come back to the main and it updates
16:54:08 * satellit usually one can find root and user spokes by change of cursor to "hand"
16:54:20 <pwhalen> but then remains static until complete..and the reboot button appears.. installs worked
16:55:30 <kalev> that sounds borderline blocker
16:56:46 <roshi> well, the install *works*
16:56:51 <pwhalen> it does
16:57:02 <satellit> same here
16:57:32 <pwhalen> more cosmetic, but it would be nice if it showed progress.. its just that bar and message right above that freeze
16:57:51 <adamw> so we can either keep them as separate bugs and throw acceptedFE at both, or pick one or the other, or call 'em dupes
16:58:03 <adamw> i'm really not clear whether we have two cases or one
16:58:08 <roshi> me either
16:58:11 <pwhalen> right
16:58:29 <roshi> pick this one since it was proposed FE and mark the other a dupe
16:58:38 <roshi> ?
16:58:46 <satellit> gtk cause? (KDE and Mate)
16:59:34 <adamw> roshi: sure, wfm.
17:00:32 <roshi> proposed #agreed - 1103496 - AcceptedFreezeException - While this is a cosmetic issue it would be great to get the fixed pulled in despite freeze.
17:02:00 <adamw> it's a bit more than just cosmetic, but sure, ack
17:02:05 <kparal> ack
17:02:17 <pwhalen> ack
17:02:52 <roshi> #agreed - 1103496 - AcceptedFreezeException - While this is a cosmetic issue it would be great to get the fixed pulled in despite freeze.
17:03:38 <roshi> #topic (1151429) preedit is visible in gnome-lock-screen for  all ibus input methods
17:03:41 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1151429
17:03:43 <roshi> #info Proposed Freeze Exceptions, gnome-shell, NEW
17:05:32 <kparal> so, has it been fixed since TC3, or is it netinst/Live-related?
17:06:02 <kparal> oh, the original report mentions Live
17:06:13 <kparal> so it seems like fixed since then
17:06:18 <kparal> should be verifiable in TC4
17:07:30 <kparal> +1 FE
17:08:09 <adamw> +1, just in case
17:08:13 <roshi> +1
17:08:32 <adamw> ask for  testing with TC4 when it lands
17:08:32 <kalev> +1
17:09:33 <kparal> oh, do we have someone doing secreatary duty?
17:09:36 <adamw> me
17:09:39 <kparal> ok, thanks
17:09:44 <adamw> it was a note that i will do that
17:10:03 <roshi> proposed #agreed - 1151429 - AcceptedFreezeException - Password input should obscure passwords regardless of input method. Please test again on TC4 when it lands.
17:10:32 <jskladan> ack
17:10:36 <kalev> ack
17:10:50 <adamw> ack
17:11:07 <roshi> #agreed - 1151429 - AcceptedFreezeException - Password input should obscure passwords regardless of input method. Please test again on TC4 when it lands.
17:11:18 <roshi> #topic (1149782) liveusb-creator creates non-booting Live USB
17:11:18 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1149782
17:11:19 <roshi> #info Proposed Freeze Exceptions, liveusb-creator, NEW
17:11:30 <satellit> just retested this
17:11:35 <satellit_e> https://fedoraproject.org/wiki/Test_Results:Fedora_21_Beta_TC3_Installation#USB_media
17:13:36 * satellit in TC2 used fat 32 USB with same results   done from f21 Beta-TC3 install to HD
17:13:47 <adamw> satellit: did you try what Luke asked you to try in the last comment?
17:13:48 <roshi> so this is a bug with liveusb-creator, not the release?
17:14:07 * satellit looking
17:14:29 <adamw> roshi: most likely, but it looks like Luke's still determining the cause
17:14:36 <satellit> but this is bios boot not EFI
17:14:46 <adamw> it's possible it winds up requiring changes to the image...
17:15:02 <adamw> satellit: well, maybe he has a reason for it all the same...i'd still try it, but also note that you're doing a BIOS boot
17:15:04 <satellit> possible shortened naming?
17:15:15 <satellit> k
17:15:38 <adamw> satellit: it's possible, but then Luke said he can't reproduce it
17:15:42 <adamw> maybe we should all give it a go
17:16:03 <roshi> checking it now
17:17:03 <adamw> anyway, my instinct would be to punt at least till we're sure where the problem is
17:17:10 <satellit> k
17:17:14 <roshi> +1 punt
17:21:08 <roshi> votes?
17:21:21 <adamw> it might be time for the cattle prod
17:21:30 * roshi can't find his USB key on his desk, so verification of this is taking longer than expected
17:21:35 <kalev> sure, +1 to punt -- voting on a FE fix before the fix is available (or at least a plan where / how to fix) is mostly pointless
17:21:43 <roshi> yup
17:22:20 <roshi> proposed #agreed - 1149782 - Punt - We'll delay FE discussion until the root cause and fix is available for discussion.
17:22:50 <kalev> ack
17:23:17 <adamw> ack
17:23:40 <jskladan> ack
17:23:46 <kparal> sorry, was on a call
17:24:16 <roshi> #agreed - 1149782 - Punt - We'll delay FE discussion until the root cause and fix is available for discussion.
17:24:29 <roshi> that's it for FEs
17:24:45 <roshi> call it a day or go over accepted blockers that are still NEW/ASSIGNED
17:24:48 <roshi> >
17:24:51 <roshi> ?
17:25:16 * adamw has a look
17:25:26 <roshi> there's 3 new/assigned in the list
17:25:36 <adamw> yeah
17:25:40 <roshi> one of which shouldn't be
17:25:50 <adamw> and that grubby one's been in POST forever
17:25:54 <adamw> pwhalen: any news on that one?
17:25:56 <roshi> 1147998 has the fix pushed
17:26:42 <pwhalen> right, needs to be pushed, which i think fesco is talking about now
17:27:14 <adamw> oh, yeah? /me looks in
17:28:57 <pwhalen> there was another bug that was a freeze exception, but dropped i would like to include in the next tc/rc as its now fixed .. looking for the bz
17:29:20 * satellit afk
17:30:05 <adamw> roshi: can you update the cloud bug to note the fix?
17:30:13 <roshi> yeah
17:30:15 <adamw> roshi: and maybe ask whoever submitted the update to edit it and mark it as fixing the bug?
17:30:24 <adamw> oh
17:30:33 <roshi> mattdm: ^^
17:30:36 <adamw> we also should discuss FE status for GNOME 3.14.1
17:31:31 <adamw> some of the bugs it fixes look FE-ish to me
17:31:44 <mattdm> what huh which?
17:32:10 <roshi> update https://bugzilla.redhat.com/show_bug.cgi?id=1147998 so that it's noted as fixed and now new :)
17:32:16 <roshi> since you pushed the fix and all :)
17:32:20 <pwhalen> would like to discuss this one - https://bugzilla.redhat.com/show_bug.cgi?id=1044778
17:32:30 <mattdm> this is the bootloader/reboot issue? I'm waiting for a tc including it to confirm
17:32:35 <pwhalen> was an accepted freeze exception, build is now in f21
17:32:38 <mattdm> should i put it as "On qa" or something?
17:32:55 <pwhalen> build here - http://koji.fedoraproject.org/koji/buildinfo?buildID=585525
17:33:09 <roshi> yeah
17:33:27 <adamw> mattdm: if there's a bodhi update that ought to fix it, can you edit the update and mark it as fixing the bug?
17:33:35 <adamw> mattdm: that way we don't have to manually shepherd it through the states
17:33:41 <pwhalen> fixes a couple other outstanding bugs reported as well as enabling a group of new boards
17:33:57 <adamw> pwhalen: so, what's to discuss?
17:34:05 <adamw> oh, do you mean build is *not* in f21?
17:34:08 <roshi> adamw: it's an edit to the kickstart - so nothing in bodhi I don't think
17:34:19 <roshi> for the cloud boot bug
17:34:20 <adamw> roshi: ah, i see
17:34:26 <adamw> so yeah, have to amend the status manually
17:35:51 <pwhalen> adamw, it was accepted and closed (fixed in rawhide).. the build is now in f21. and i didnt see it listed.. would like to ensure it gets pulled in
17:36:52 <adamw> pwhalen: well, the status isn't always accurate, it may well have been built in f21 too
17:37:10 <mattdm> adamw no it's a spin-kickstarts hack
17:37:34 <adamw> pwhalen: have you actually checked and seen that it's not in f21, or are you just not sure?
17:37:38 <pwhalen> adamw, it hadnt
17:37:43 <pwhalen> sure
17:37:51 <adamw> ok, so in that case we can re-open and re-apply the FE status
17:37:56 <pwhalen> ok, will do
17:38:04 <danofsatx> oh, there's a meeting?
17:38:09 <adamw> pwhalen: i can do it as secretary
17:38:10 * danofsatx didn't read his email :(
17:38:16 <adamw> danofsatx: same time, same place ;)
17:38:22 <pwhalen> adamw, why thank you :)
17:38:30 <danofsatx> what day is it, anyhow?
17:38:57 <roshi> danofsatx: I didn't ping you since I thought you had to be somewhere
17:39:20 <roshi> something about "have to do this thing within 2 hours when I have to leave"
17:39:37 <adamw> danofsatx: Geldof
17:40:03 <kalev> I wanted to bring up GNOME 3.14.1, would it be a good time now?
17:40:11 <roshi> yeah kalev
17:40:21 * adamw tried once already :)
17:40:28 <kalev> so, there's a new point release for GNOME and barely missed the freeze
17:40:38 <adamw> is it strictly a bugfix release?
17:40:45 <kalev> bringing a month's worth of bug fixes -- would be awesome to have that in the release to get more testing
17:40:54 <kalev> adamw: yep, we're in bug fix only mode upstream
17:41:37 <danofsatx> I do have to be somewhere, but I just cancelled that. Stuck making F21 talk to Active Directory.....this is muy fun.
17:41:44 <kalev> it's a pretty big update and touches a lot of components, so I wouldn't be comfortable pulling it in before it's gotten some good karma points
17:41:56 <adamw> i'm probably +1 to it, then - as i mentioned, the list of individual bugs it fixes includes some that look like we'd want them in
17:42:24 <kalev> so what I'd like to ask here is to pull it in for the next TC
17:42:39 <adamw> well, after freeze we only do that for things that have been granted FE
17:42:39 <kalev> and decide after seeing how it fares in updates-testing whether to push it to stable or not
17:43:10 <adamw> i don't think we need to do that for GNOME, because it'll get plenty of testing from folks who already have f21 installed
17:43:18 <adamw> u-t is enabled by default for branched, so they will get it despite the freeze
17:43:27 <roshi> true
17:43:37 <adamw> what i'd suggest is you file a bug for '3.14.1 in F21 Beta' and propose it as FE
17:43:47 <adamw> and we can then vote async (with BZ comments) once karma comes in
17:44:04 <kalev> sure, sounds good to me
17:44:37 <kalev> also, if anyone wants to test it before it hits updates-testing, I have a secret repo that includes all the packages :)
17:45:20 <adamw> kalev: you can suck it out of bodhi
17:45:32 <adamw> bodhi -D (some EVR from the update)
17:46:42 <kparal> or the update id
17:46:50 <adamw> yeah, though it doesn't get one right away
17:47:01 <kparal> ah, right. only after it's pushed to u-t
17:47:49 <kalev> anyway, I just wanted to get this on everyone's radar
17:48:00 <kalev> let's wait for it to hit updates-testing first and vote on the FE status then
17:48:12 <roshi> works for me
17:48:13 <kalev> would be good to pull it in this week _if_ we decided to include it
17:48:33 <adamw> kalev: if you can CC the folks who usually show up at meetings and stuff on the bug it'll help get votes
17:48:36 <kalev> otherwise we might not have time to fix up stuff if anything regresses
17:48:39 <kalev> adamw: ok, will do
17:49:05 <adamw> kalev: i'm thinking i might want to do a TC4/RC1 today since it seems like we have some significant bits to pull in - new anaconda build and this ARM grubby change
17:49:59 <kalev> arr, would be great to have this pulled in for there but it hasn't even hit updates-testing yet :(
17:50:09 <adamw> but then 3.14.1 can be pulled for the next one (if we +1 it)
17:50:54 <kalev> sounds like a plan
17:51:48 <adamw> ok, so...
17:52:17 <adamw> that leaves one blivet bug and the udev bug in fedup as the blockers
17:52:28 <adamw> systemd folks all seem to be at a conference in europe
17:53:03 <roshi> seems there's a conference every month
17:54:47 <roshi> anything else for us to discuss here?
17:56:08 <adamw> don't think so, looks like we'll be on TC4 next, hope for RC1 once we can get the udev bug fixed (i'm expecting that'll be the last one)
17:56:18 <roshi> works for me
17:56:21 <adamw> i'll ping dlehman on the NTFS corruption bug
17:56:28 <roshi> I'll close the meeting then
17:56:49 <roshi> fix my irssi server...
17:56:54 <roshi> thanks for coming all!
17:57:05 * roshi sets short fuse
17:57:47 <adamw> btoom
17:57:54 <adamw> thanks for running, roshi!
17:58:23 <roshi> np - thanks for secretializing
17:59:08 <roshi> #endmeeting