16:00:03 <tflink> #startmeeting f19alpha-blocker-review-6
16:00:03 <zodbot> Meeting started Wed Apr 10 16:00:03 2013 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:03 <tflink> #meetingname f19alpha-blocker-review-6
16:00:03 <zodbot> The meeting name has been set to 'f19alpha-blocker-review-6'
16:00:03 <tflink> #topic Roll Call
16:00:21 <tflink> Who's ready for some blocker review awesome fun time?
16:00:26 * satellit listening
16:01:34 * kparal around, but hunting for food
16:02:00 * jreznik is here
16:02:23 <jreznik> (needs a moment)
16:02:49 <tflink> kparal: impressive that you can hunt and be on IRC at the same time
16:03:15 <tflink> be vewwwy, vewwwy qwiet ... kparal's hunting for wabbits
16:03:37 * kparal is going to pillage the company fridge now
16:03:45 * tflink isn't sure if that reference is common enough to work outside the US
16:04:11 <kparal> nope
16:04:16 <tflink> any volunteers to play secretary?
16:04:52 <tflink> http://en.wikipedia.org/wiki/Elmer_Fudd
16:06:57 <kparal> tflink: ah, that one. I saw a few episodes
16:08:04 * tflink is hoping for at least one more active participant
16:08:38 <tflink> adamw: you around?
16:10:15 * Martix is partialy here (multitasking today between mtgs)
16:10:24 * nirik is lurking, but doing other things.
16:10:42 * jreznik will pretend being active participant :)
16:10:47 <tflink> well, let's get started and see what happens. I can secretarialize afterwards if need be
16:11:18 <tflink> jreznik: sounds like you need adamw's moustache
16:11:24 <tflink> #topic Introduction
16:11:30 <tflink> Why are we here?
16:11:30 <tflink> #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:11:37 <tflink> #info We'll be following the process outlined at:
16:11:38 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:11:42 <tflink> #info The bugs up for review today are available at:
16:11:43 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:11:48 <tflink> #info The criteria for release blocking bugs can be found at:
16:11:48 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria
16:11:55 <tflink> #info Up for review today, we have:
16:12:02 <tflink> #info 2 Proposed Blockers
16:12:02 <tflink> #info 4 Accepted Blockers
16:12:02 <tflink> #info 7 Proposed Freeze Exceptions
16:12:02 <tflink> #info 7 Accepted Freeze Exceptions
16:12:34 <tflink> if there are no objections, I'll start with the proposed blockers
16:12:45 <tflink> #topic (950593) FormatDestroyError: error wiping old signatures from /dev/mapper/mpatha: 1
16:12:48 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=950593
16:12:50 <tflink> #info Proposed Blocker, anaconda, NEW
16:13:55 <tflink> I forget, where does mpath fit in the release criteria
16:14:04 <nirik> not sure.
16:14:06 * jreznik is taking look
16:14:11 <tflink> other than I think most ppc/s390 machines are going to have mpath storage
16:14:41 * tflink really needs to get the new blocker tracking app upgrade done
16:14:56 <tflink> we were doing so well on people citing criteria for a while
16:15:00 <tflink> hamzy: just in time
16:15:11 <tflink> we're discussing 950593
16:15:21 <hamzy> did I not cite something?
16:15:38 <hamzy> sorry
16:16:09 <tflink> no worries, you wouldn't be the first and I think it's more a product of a complicated, poorly communicated process
16:16:25 <jreznik> tflink: well, we are not sure where mpath fits in release criteria, so it's hard to request is...
16:16:44 <tflink> I'm thinking not alpha
16:17:08 <kparal> I don't think it's Alpha
16:17:18 <jreznik> The installer must be able to complete an installation using any supported locally connected storage interface.  and 'Locally connected storage interfaces' include PATA, SATA and SCSI.
16:17:18 <kparal> rather Final
16:17:57 <dlehman> the fix is trivial FWIW, but might have some risk
16:18:20 <dlehman> (proposed fix is to pass  -f to all wipefs invocations)
16:18:20 <tflink> yeah, I'd rather avoid that on the day before go/no-go
16:18:40 <jreznik> yep, anyone with better overview of criteria?
16:18:52 <hamzy> I'm just worried that the amount of testing is shortened if we can't move past this issue... there might be other issues with multipath since it is not well tested
16:18:53 * jreznik can't find it by searching
16:18:53 <dlehman> I'm fine either way given how little testing mpath gets during alpha anyway
16:18:57 <tflink> yeah, mpath is final
16:19:11 <tflink> "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)"
16:19:25 <tflink> -1 alpha blocker
16:19:26 <dlehman> hamzy: we can put an updates image somewhere for people who want to test mpath if that helps
16:19:28 <jreznik> hamzy: shortly after Alpha we start spinning Beta TCs... so we will have more time
16:19:37 <jreznik> -1 alpha blocker
16:19:57 <hamzy> ok
16:20:14 <jreznik> kparal: ? & others?
16:20:31 <kparal> -1
16:21:17 <tflink> proposed #agreed 950593 - RejectedBlocker - problems with mpath storage do not violate any f19 alpha release criteria and thus, this bug is rejected as a blocker for F19 alpha.
16:21:29 <jreznik> ack
16:21:30 <tflink> if we weren't so close to go/no-go, I'd be OK with FE
16:21:41 <jreznik> tflink: I'd like to avoid FE for now...
16:21:51 <jreznik> especially when dlehman stated there's some risk
16:22:11 <tflink> jreznik: same here. like I said, if we weren't so close to go/no-go :)
16:22:23 <tflink> other ack/nak/patch?
16:22:35 <dlehman> not sure if there's any _real_ risk TBH but it is a change in a destructive area
16:22:35 * j_dulaney waves
16:22:50 <kparal> ack
16:23:17 <tflink> if we end up slipping, we can look at FE
16:23:20 <nirik> ack
16:23:38 <jreznik> tflink: definitely
16:23:44 <tflink> #agreed 950593 - RejectedBlocker - problems with mpath storage do not violate any f19 alpha release criteria and thus, this bug is rejected as a blocker for F19 alpha.
16:23:53 <tflink> #topic (947142) write to /sys/firmware/efi/vars/new_var results in ENOSPC
16:23:56 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=947142
16:23:58 <tflink> #info Proposed Blocker, kernel, NEW
16:25:05 <jreznik> this one seems tough - to understand the risk of not having it and how many people could be affected
16:25:12 <adamw> morning morning
16:25:22 <adamw> sorry, cleaning up
16:25:23 <jreznik> adamw: morning adamw!
16:25:46 <tflink> adamw: not acceptable!
16:25:50 <tflink> .fire adamw
16:25:50 <zodbot> adamw fires adamw
16:25:56 <adamw> why, I oughta...
16:26:05 <kparal> there are definitely several UEFI problems. but the root cause might be different for each of them
16:26:06 <j_dulaney> adamw:  I've only just arrived, too
16:26:46 <jreznik> kparal: yep, from what I saw - seems like many different ones
16:27:18 <tflink> I had issues with a uefi install yesterday but haven't quite figured out what happened yet
16:27:18 * j_dulaney is leaning -1 blocker, but do we know how many people this affects?
16:28:01 <adamw> we don't, really, no.
16:28:05 <tflink> kparal: were you able to finish a uefi install on the asus box you mentioned?
16:28:18 <kparal> tflink: no, because of https://bugzilla.redhat.com/show_bug.cgi?id=950022
16:28:40 <kparal> but I haven't tried several attempts, just one
16:28:48 <jreznik> adamw: well, there's a comment by jwb https://bugzilla.redhat.com/show_bug.cgi?id=947142#c7
16:30:03 <tflink> so we have multiple uefi issues and no really clear picture on who's affected by which issue(s) ...
16:30:30 <tflink> has anyone tried F19 SB?
16:30:44 * j_dulaney thinks sometimes it's good to have old hardware
16:30:55 <adamw> tflink: not yet
16:31:02 <adamw> (afaik)
16:31:15 <j_dulaney> What's the status of SB and KVM?
16:31:36 <tflink> I haven't tried SB with ovmf, just uefi emulation
16:31:36 <adamw> what does KVM have to do with anything?
16:31:44 <adamw> oh, you mean SB in a VM? there's a wiki page about it.
16:32:01 * j_dulaney looks
16:32:02 <tflink> IIRC, the process is a bit odd but it would be better than nothing
16:32:04 <adamw> i don't see what SB has to do with this, though.
16:32:14 <tflink> just curious
16:32:16 * j_dulaney will give it a go this afternoon
16:32:18 <tflink> not directly related
16:32:25 <jreznik> first you need working EUFI -> then SB
16:32:27 <adamw> so really, all we know is that some UEFI installs will fail.
16:32:43 <tflink> it kinda sounds like this isn't all that common
16:33:13 <tflink> 950022 worries me a bit more, to be honest
16:33:18 <adamw> well, the only thing that worries me is that apparently botgh the people in the meeting who've tried a metal UEFI install got a fail...
16:33:21 <tflink> assuming that they're not related
16:33:48 <tflink> my litd just finished to try again with RC2
16:35:02 <adamw> proposal: shall we defer and try and get as much testing as possible?
16:35:12 <adamw> i can do an install on this system, there's probably a few other people with UEFI boxes
16:35:25 <adamw> ask everyone to do as clean as possible a test with RC2 and see what happens
16:35:30 <tflink> yeah, I don't think we have much of a choice here unless we want to pause the meeting while we test
16:36:08 <j_dulaney> ack
16:36:20 * jreznik would expect more UEFI testing during TCs etc but understands how many test cases we have...
16:36:30 <tflink> proposed #agreed 947142 - We need more data on how many systems are affected by this and 950022 before making a decision on release blocking status for F19 alpha - will revisit after more testing is done
16:36:35 <tflink> ack/nak/patch?
16:36:41 <tflink> and before I forget again ...
16:36:47 <tflink> #chair adamw kparal
16:36:47 <zodbot> Current chairs: adamw kparal tflink
16:37:05 <adamw> ack
16:37:06 <kparal> ack
16:37:07 <j_dulaney> ack
16:37:21 <jreznik> ack
16:37:42 <tflink> #agreed 947142 - We need more data on how many systems are affected by this and 950022 before making a decision on release blocking status for F19 alpha - will revisit after more testing is done
16:37:58 <tflink> kparal: would you mind proposing 950022 as a blocker?
16:38:39 <kparal> tflink: I will
16:38:41 <tflink> that's all of the proposed blockers for today
16:38:52 * tflink looks through the list of proposed FE
16:38:55 <tflink> kparal: thanks
16:39:31 <tflink> the only one I'm seeing is
16:39:34 <tflink> #topic (949002) anaconda crashes while trying to select wireless network
16:39:37 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=949002
16:39:40 <tflink> #info Proposed Freeze Exceptions, anaconda, POST
16:40:16 <tflink> do we want to take this as FE this late with apparently no testing?
16:40:24 * tflink is leaning towards no
16:40:38 <j_dulaney> Well, considering a new Anaconda is likely to be pulled in, anyway
16:40:44 * j_dulaney votes defer to next week
16:41:19 <adamw> we'd only get a new anaconda if we decide the uefi issues are a blocker and the fix is in anaconda (neither is a given)
16:41:40 <adamw> in fact the 'fix is in anaconda' part is quite unlikely
16:42:23 <tflink> j_dulaney: hopefully there will be no "next week" for alpha
16:42:45 <j_dulaney> Aye
16:43:08 <tflink> sounds like either reject or punt
16:43:09 <adamw> I guess -1 for the present, or defer in case of a slip
16:43:41 * j_dulaney is -1 or punt, depending
16:44:12 <tflink> proposed #agreed 949002 - This doesn't have enough testing to take as a FE so late but it's a possibility if alpha does end up slipping - will revisit later if more blocker review meetings are required
16:44:49 <tflink> ack/nack-patch?
16:44:56 <jreznik> ack
16:45:09 <adamw> ack
16:45:43 <kparal> ack
16:45:45 <tflink> #agreed 949002 - This doesn't have enough testing to take as a FE so late but it's a possibility if alpha does end up slipping - will revisit later if more blocker review meetings are required
16:46:31 <tflink> ok, that was the only proposed FE that was ready for discussion
16:46:47 * j_dulaney phears
16:47:00 <j_dulaney> Blocker meeting this late and only 45 minutes?
16:47:00 <tflink> there is one non-ON_QA/VERIFIED blocker but methinks that needs an updated status
16:47:12 <tflink> j_dulaney: shush, you'll jinx us
16:47:32 <tflink> #topic (949831) Fedora 19 RC1 - Cannot open theme file /usr/share/kde4/apps/kdm/themes/SphericalCow - Wrong default theme
16:47:35 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=949831
16:47:38 <tflink> #info Accepted Blocker, kde-settings, MODIFIED
16:47:41 <adamw> yeah, i'll update that.
16:47:46 <adamw> has someone tested kde with rc2 yet?
16:47:48 <tflink> I think this was included in RC2 and can be moved to ON_QA or VERIFIED
16:47:57 <jreznik> there's comment that it works
16:48:02 <adamw> ah, mkrizek
16:48:03 <adamw> yup
16:48:09 <tflink> yeah, it sounds like mkrizek tested it with RC2
16:48:54 <tflink> #info this was included in RC2, has been tested - move to VERIFIED
16:49:05 <adamw> actually it was pushed stable, so I closed
16:49:13 <tflink> I think that's it for today, did I miss anything?
16:49:15 <tflink> #undo
16:49:15 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x29499c50>
16:49:40 <tflink> #info this was included in RC2, has been tested and has enough karma to be pushed stable - move to CLOSED
16:50:21 <jreznik> status for 949912?
16:50:35 <tflink> 949912?
16:50:55 <adamw> the one we did rc2 for
16:51:07 <adamw> the fix is in rc2, but doesn't look like anyone's tested it
16:51:26 <jreznik> that's why I'm asking if anyone had a chance to test it
16:52:08 * tflink hasn't
16:53:42 <tflink> any volunteers to send out a request for blocker fix testing?
16:54:51 * j_dulaney can
16:55:06 <adamw> i'll poke the bug
16:55:16 <jreznik> thanks
16:55:42 * j_dulaney is writing email
16:56:02 <tflink> j_dulaney: thanks
16:56:19 <tflink> it sounds like it's time for ...
16:56:22 * kparal notes mgarrett just duped the two uefi bugs: https://bugzilla.redhat.com/show_bug.cgi?id=950022#c13
16:56:33 <tflink> #topic Open Floor
16:56:55 <tflink> do we want to keep the meeting going while we collectively poke at the uefi bugs?
16:57:03 <tflink> or reconviene later?
16:57:12 * tflink wishes irssi had spell check sometimes
16:57:51 <adamw> eh, either way
16:58:13 * tflink doesn't care either
16:59:04 <j_dulaney> +1 for irssi and spell checker
16:59:07 <jreznik> kparal: mjg just closed your bug as duplicate - see #fedora-devel
16:59:16 <tflink> eh, lets just keep the meeting going - that's one reason why we had a dedicated channel created anyways
16:59:19 <kparal> jreznik: see my last comment :)
16:59:42 <jreznik> kparal: ok, ok :D
16:59:48 <kparal> it seems that quite a few boards are affected by that bug
16:59:52 <kparal> (uefi)
17:00:13 <kparal> I can't probably test any more, if it's broken, it's broken
17:10:04 <kparal> so what are we waiting for right now?
17:10:18 <tflink> UEFI testing
17:10:23 <kparal> ok
17:10:49 <tflink> figured we could just keep the meeting running since nobody else is going to use the channel
17:12:50 * jreznik will try to follow the meeting but does not have UEFI system he could give a hand
17:15:00 <j_dulaney> jreznik:  You can do it with ovmf
17:15:10 * j_dulaney is setting up now to do so
02:49:42 <tflink> I suppose that we should wind this up at some point
02:49:46 <tflink> epic meeting?
02:50:12 <tflink> anyhow, I'll send out minutes shortly - it looks like we have some fun bugs to deal with
02:50:18 <tflink> #endmeeting