15:00:07 <jlaska> #startmeeting F12 Alpha Blocker Review
15:00:26 <poelcat> jlaska: good day
15:00:34 <jlaska> #topic gathering
15:01:17 <jlaska> I see a few usual suspect, can we do a quick roll call?
15:01:47 * poelcat 
15:01:51 * mclasen lurks
15:01:55 * Sparks_too is here
15:02:11 * tk009 
15:03:16 * sseiersen|Laptop is watching
15:03:53 * iarlyy is here
15:04:58 <jlaska> okay, starting momentarily ... going to wait for rel-eng (f13) and see if adamw can join as well
15:06:45 * notting is here
15:07:00 <notting> oh feh. no images today?
15:07:20 <iarlyy> notting, hey guy, are you fine?
15:07:22 <jlaska> really?
15:07:29 <notting> jlaska: don't see them
15:07:37 * jlaska done a few rawhide installs today
15:07:45 <jlaska> from download.fedora.devel.redhat.com ... is it old content?
15:07:51 <jlaska> if so,  Ithink we have a new blocker :)
15:07:52 <notting> maybe
15:07:53 <mclasen> notting: are you talking about isos or about ascii art ?
15:08:02 <notting> mclasen: boot.iso, etc.
15:08:31 <jlaska> hmm, I'm seeing them up on d.fedora.redhat.com
15:08:41 <jlaska> okay folks, let's get this show on the road
15:09:00 <jlaska> Let's start by walking down the F12Alpha list which has been getting some exercise this week
15:09:04 <jlaska> https://bugzilla.redhat.com/showdependencytree.cgi?id=507676&hide_resolved=1
15:09:22 <jlaska> #topic bug#499854 - https://bugzilla.redhat.com/show_bug.cgi?id=499854
15:09:28 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=499854 high, low, ---, jgranado, MODIFIED, filedescriptor out of range in select()
15:09:28 <buggbot> Bug 499854: high, low, ---, jgranado, MODIFIED, filedescriptor out of range in select()
15:10:03 <jlaska> appears a fix was pushed into anaconda-12.9, and Clyde tested with a custom boot.iso built by f13 that included 12.10
15:10:26 <jlaska> Clyde indicated the problem remains, I think that means we should bump this back to ASSIGNED
15:11:18 <jlaska> let me see if jgranados can join
15:11:48 <notting> jlaska: oh, nice. rawhide failed entirely.
15:11:53 <notting> head -> desk.
15:12:07 <jlaska> notting: I'll checkin shortly
15:12:09 * daMaestro lurks
15:12:15 <jlaska> jgranados: thanks for joining
15:12:24 <jlaska> we are talking about Clyde's latest update to 499854
15:12:34 <jlaska> based on his feedback, I'd like to move this back to ASSIGNED
15:12:35 * jgranados looks
15:14:00 <jlaska> In some ways this is an old bug, but Clyde has demonstrated his ability in capturing fairly high profile anaconda bugs in the past
15:14:30 <jlaska> and I believe it is blocking testing on the Alpha for Clyde
15:15:09 * maxamillion is here ... late, sorry ($dayjob)
15:15:21 <jlaska> maxamillion: hello
15:16:03 <jgranados> jlaska : hrm.. strange...
15:16:12 <jgranados> jlaska : I'll take a look.
15:17:08 <jlaska> okay, I'd recommend moving this to ASSIGNED and keeping on the list until we have a better undertanding of the problem
15:17:15 <jlaska> any objections/alternatives?
15:17:17 <jgranados> jlaska : ok
15:17:22 <jgranados> jlaska : fine by me.
15:17:38 <maxamillion> none here
15:18:16 <jlaska> #agreed Move 499854 to ASSIGNED, and reassess blocker potential after jgranados has had a chance to review
15:18:33 <jlaska> okay next up ...
15:18:43 <jlaska> #topic bug#512845 - https://bugzilla.redhat.com/show_bug.cgi?id=512845
15:18:46 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=512845 high, high, ---, stransky, ASSIGNED, setroubleshoot:      SELinux is preventing firefox from changing a writable memory segment executable.
15:18:46 <buggbot> Bug 512845: high, high, ---, stransky, ASSIGNED, setroubleshoot:      SELinux is preventing firefox from changing a writable memory segment executable.
15:19:00 <poelcat> quick question... i'm seeing several "nfs installs don't work"... should they block F12Alpha?
15:19:13 * poelcat moved a few.. appologizes if that was too hasty
15:20:01 <jlaska> poelcat: clumens and were discussion those before the meeting, I need to inspect the problems further to determine if that are part of the tier#1 install tests, or if they are issues outside the install alpha criteria
15:20:16 <poelcat> jlaska: got it
15:20:41 <jlaska> notting: you've got the last touch on this bug, do you have any updates?
15:20:51 <notting> no
15:20:56 * jlaska reading
15:21:12 <notting> somewhat confused why it would show up now, unless XR grew a JIT very recently
15:21:26 <jlaska> afaik ... this issue is keeping firefox from running in Enforcing mode?
15:21:34 <notting> on 32-bit x86
15:22:08 <maxamillion> jlaska: yes
15:22:31 <maxamillion> random side note that's related, was the SELinux+NM bug addressed already?
15:22:54 <jlaska> not sure ... but if you find that it wasn't, feel free to add to the list for review
15:23:05 <jgranados> jlaska : I have tested once more in my environment and I can't see 499854.
15:23:10 <jgranados> is clyde here?
15:23:13 <jlaska> he is not
15:23:30 <jlaska> jgranados: not sure if remote access to his system is an option
15:24:03 <jlaska> firefox not starting with a default install seems like a valid blocker on the alpha
15:24:15 <jlaska> but it's not clear what the next course of action is for this issue
15:24:21 <Alticon-Brian> i just had to grab the updated xulrunner and firefox from koji
15:24:36 <jlaska> notting: are there particular people that we should pull in on this?
15:25:05 <notting> get caillon/stransky/jhorak on the line and see if they can disable the jit in the meantime?
15:25:05 <maxamillion> Alticon-Brian: is this fixed in the latest xulrunner/firefox in koji?
15:25:12 <Alticon-Brian> well, it
15:25:16 * jlaska goes to find them
15:25:29 <Alticon-Brian> http://koji.fedoraproject.org/koji/buildinfo?buildID=126008
15:25:33 <Alticon-Brian> there's xulrunner at least
15:25:39 <Alticon-Brian> firefox starts
15:25:43 <jlaska> Alticon-Brian: that resolved the problem for you?
15:25:44 <Alticon-Brian> but has the same old selinux errors again
15:26:40 <Alticon-Brian> so i just chcon the firefox directory
15:26:45 <Alticon-Brian> and everything plays nicely again
15:26:48 <jlaska> okay, I'm not finding any of them online at the moment
15:27:00 <maxamillion> :(
15:27:05 <jlaska> anyone want to take an action to follow-up with them?
15:27:42 <jlaska> #action follow-up with caillon/stransky/jhorak to disable the jit for Alpha
15:27:47 <maxamillion> I can ping them on it, I'll shoot out an email to f-d-l I guess
15:27:58 <jlaska> maxamillion: thanks!
15:28:00 <f13> hrm.
15:28:14 <maxamillion> that way we might even get some others to chime in
15:28:15 <maxamillion> f13: ?
15:28:26 <f13> seems I forgot to put this new blocker day in my calendar
15:28:56 <f13> maxamillion: blocker review day.  This one didn't exist a couple weeks ago
15:29:16 <jlaska> #agreed reach out to caillon/stransky/jhorak for input on disabling jit in F-12-Alpha firefox ... remain as a blocker
15:29:17 <maxamillion> f13: ohhhh, I dunno ... just saw the email yesterday
15:29:29 <jlaska> okay ... next up ...
15:29:35 <jgranados> jlaska : another question is, did Clyde get passed 516168?
15:29:44 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=513879
15:29:46 <buggbot> Bug 513879: medium, low, ---, katzj, MODIFIED, Rawhide anaconda not using correct gtk theme
15:29:50 <f13> jlaska: is it truly a blocker since a workaround exists and we could have it fixed in rawhide before alpha comes out?
15:29:55 <f13> jlaska: is it worth slipping the release for?
15:30:08 <f13> 513879 is fixed upstream.
15:30:16 <f13> I confirmed the fix (well I made the fix)
15:30:25 <maxamillion> lol
15:30:29 <jlaska> f13: firefox not working out of the box is a tough one
15:30:29 <f13> we don't have a build with that fix in rawhide because the build with that fix regressed in other ways
15:30:41 <f13> jlaska: it's only not working out of the box for i386 people with selinux enabled
15:30:48 <f13> and thats if they don't do any of the 0-day updates
15:31:28 <jlaska> f13: I'd like to hear back from the maintainers on this ... but having a workaround is definitely a positive
15:31:41 <jlaska> f13: can you post the steps you did to workaround the issue in the bz?
15:31:49 <maxamillion> jlaska: if caillon/stransky/jhorak gets the JIT disabled in rawhide ... today-ish, would that make it alright for the alpha and then we make it with the JIT on a beta blocker?
15:32:19 <f13> jlaska: I haven't even tried, I don't have an i386 host around here (:  booting with selinux in permissive should work.
15:32:35 <f13> maxamillion: it'd be close, depends on how long it takes for those packages to build.
15:32:42 <f13> (and how late I stay up to compose the RC)
15:33:05 <notting> jlaska: i'm not sure booting with selinux permissive is a workaround we want to push
15:33:11 <jlaska> I agree
15:33:18 <jlaska> not for firefox
15:33:22 <adamw> morning
15:33:23 <maxamillion> f13: rgr
15:33:25 <f13> it's a workaround until you install the updates
15:33:25 <maxamillion> adamw: hi hi
15:33:28 <notting> f13: hm, maybe discuss scheduling after we get through the list? might be a moot discussion by that point.
15:33:29 <adamw> sorry, guys, my alarm didn't go off
15:33:36 <f13> it's not like people are going to install Alpha and then not update it for the next 6 months.
15:33:45 <jlaska> notting: thanks yes. .. for now we are just reviewing the bugs for blocker material
15:33:47 <maxamillion> f13: true
15:34:06 <adamw> where are we?
15:34:18 <poelcat> adamw: arguing about what a blocker is :)
15:34:20 <jlaska> we've moved back to previous topic as f13 has concerns
15:34:31 <jlaska> bug#512845
15:34:32 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=512845 high, high, ---, stransky, ASSIGNED, setroubleshoot:      SELinux is preventing firefox from changing a writable memory segment executable.
15:34:33 <f13> I'm happy to re-visit after the rest of the list
15:34:50 <maxamillion> f13: can't someone who has provenpackager status make a patch to the spec and make a build? ... or would that cause toe-stepping?
15:35:18 <maxamillion> because iirc provenpackagers can commit to anything not explicitly excluding them, right?
15:35:35 <jlaska> maxamillion: right now, I think we just need to decide if it blocks ... but not necesarily the details of how to fix it (while that still is valuable)
15:35:44 <notting> maxamillion: a) ff/xr is special. b) it's not at all clear if it's a 'simple' patche
15:35:49 <f13> maxamillion: patches to firefox are a touchy subject, as the trademark comes into play
15:35:56 <adamw> so, firefox doesn't work with selinux enabled on x86-32
15:35:58 <maxamillion> f13: ahhh, gotchya
15:36:08 <f13> adamw: or permissive
15:36:13 <adamw> erk
15:36:48 <maxamillion> jlaska: fair enough
15:36:57 <adamw> if we're sticking to our guns on blocker-ness, it can't be a blocker. on the other hand, on a practical level, we'd have to be very careful from a pr angle, releasing a pre-release with firefox broken...
15:37:06 <maxamillion> should we move the topic of the fix to #fedora-devel after this meeting is over?
15:37:26 <jlaska> adamw: that's where my concern on this issue comes from
15:37:47 <jlaska> maxamillion: yeah, that might be appropriate
15:37:48 <f13> adamw: the idea being that we'd have it fixed in rawhide by the time Alpha is publicly released
15:37:59 <f13> so if people update before launching the browser....
15:38:13 <maxamillion> :/
15:38:27 <maxamillion> I don't think many will though
15:38:30 <jlaska> ermm, that's rough
15:38:33 * poelcat thinks we can't predict that
15:38:57 <jlaska> so let's take score so we can move on
15:39:02 <adamw> yeah, my feeling is that's not likely
15:39:02 <adamw> most people install and then want to _try_ the thing, and firefox is probably one of the first things they run.
15:39:42 <maxamillion> adamw: agreed
15:40:00 <f13> then should FF be added to the critical path?
15:40:03 <f13> (is it there already?)
15:40:13 * poelcat votes for moving on and circling back
15:40:29 <jlaska> #idea f13 asks ... should firefox be added to critical path
15:40:34 <jlaska> f13: we can come back to that
15:41:35 <jlaska> I think the consensus is to keep this on the list, and f13 introduces a valid recovery plan if needed
15:42:18 <jlaska> folks ready to move on to #topic bug?
15:42:39 <f13> yes
15:42:52 <notting> f13: sorry, i broke it
15:42:58 <jlaska> and f13 fixed it!
15:43:22 <jlaska> so it's in MODIFIED and awaiting tagging+compose is that accurate?
15:43:29 <f13> sortof
15:43:35 <notting> (working build)+ tag + compose
15:43:42 <f13> we're waiting for further anaconda fixes before tagging and composing
15:43:49 <f13> so it's blocked by newer bugs
15:43:57 <jlaska> right on ... I see a few other ones coming up :)
15:44:13 <jlaska> any additional action needed here, or just wait for verification when possible?
15:44:58 <f13> just wait really.
15:45:06 <f13> there may be more fixes in this area to get the X cursor right
15:45:38 <jlaska> #agreed 513879 in MODIFIED and awaiting verification once tagged and composed for the Alpha
15:45:48 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=515091
15:45:49 <buggbot> Bug 515091: medium, low, ---, msivak, MODIFIED, rescue mode fails: not all arguments converted; open("/etc/mtab", ...
15:46:01 <adamw> sorry, one second
15:46:11 <adamw> when we talk about 513879, _which_ bug are we talking about?
15:46:20 <jlaska> ah good question
15:46:25 <adamw> the wrong GTK theme or the cursor issue?
15:46:31 <adamw> cos i'm afraid i still don't think they're duplicates :)
15:46:33 <f13> wrong GTK theme
15:46:37 <f13> cursor one is different
15:46:44 <adamw> f13: not so far as bugzilla's concerned
15:46:46 <f13> (since they are different themes)
15:46:51 <adamw> f13: cursor issue has been marked as a dupe of this bug
15:46:58 <jlaska> f13: can that fix be confirmed with your boot.iso?
15:46:58 <f13> there is a gtk theme, an icon theme, and a cursor theme
15:47:06 <adamw> cursor issue is https://bugzilla.redhat.com/show_bug.cgi?id=515410 , we won't hit it otherwise as it's marked dupe of 513879
15:47:08 <buggbot> Bug 515410: medium, low, ---, anaconda-maint-list, CLOSED DUPLICATE, f12 anaconda mouse was not initialized during installation on stage 2
15:47:11 <f13> adamw: it's not, it needs to be unduped and put on the blocker list
15:47:36 <f13> jlaska: "that fix" ?
15:47:45 <adamw> that was my belief and jlaska's too, i think all three of us outvote andy...i'm de-duping it
15:47:53 <jlaska> adamw: thanks
15:48:09 <f13> the reasons for the breakage are vastly different too
15:48:09 <jlaska> f13: is the fix for 513879 included in that boot.iso you posted to anaconda-devel-list?
15:48:20 <f13> jlaska: yes, the fix for the gtk theme
15:48:58 <f13> for the GTK theme, we just simply weren't getting the theme files in install.img due to a incomplete upd-instroot run
15:49:04 <jlaska> adamw: we can add that UNDUP'D issue to the end of the list
15:49:05 <adamw> ok, i de-duped 515410 and marked it blocking alpha
15:49:14 <adamw> jlaska: yup, throw it on there
15:49:15 <f13> the missing cursor is due to improper discovery of the cursor theme
15:49:55 <jlaska> okay, let's move on
15:50:08 <f13> I'm using my boot.iso to test rescue mode
15:50:41 <f13> and it tracebacks with the same thing regular installs do
15:50:57 <f13> so testing of this is blocked by 516168
15:51:20 <adamw> i'm with jlaska on this one, i don't think it's really an alpha blocker
15:51:40 <jlaska> adamw: for 515091?
15:51:43 <f13> rescue not a blocker?
15:51:57 <adamw> practically speaking, there's no need to use the rescue mode specifically from an alpha image, if we fix it after release you can just use rescue mode from a rawhide installer image, right?
15:52:02 <adamw> jlaska: f13: yes
15:52:16 <jlaska> adamw: it doesn't meet the bar we've established in that it is a tier#2 test
15:52:19 <maxamillion> can't you use a stable liveCD for rescue purposes?
15:52:24 <f13> adamw: unless your hardware doesn't work with older media
15:52:36 <jlaska> however, I think it's worth considering as rescue-mode is your only recovery/debugging option when installation goes south
15:53:03 <f13> the anaconda team should probably chime in as to whether or not they consider rescue mode to be blocker worthy
15:53:06 <adamw> 'worth considering' doesn't make it a blocker, though, and this is the last review before go/no-go meeting, we should be bumping things that we won't really delay a release for
15:53:07 <f13> blocker/slip worthy
15:53:08 <poelcat> jlaska: link handy for tier#1 and #2 tests?
15:53:18 <jlaska> https://fedoraproject.org/wiki/QA:Fedora_12_Alpha_Install_Test_Results
15:53:42 <adamw> f13: uh, 'older' media? I said 'rawhide', that would be newer than the alpha :) actually max points out you could try an 'older' image (from a stable release) too, so both angles are covered there
15:54:28 <maxamillion> the main reason I bring it up is because I always have a stable liveCD handy when playing around with rawhide
15:54:52 <jlaska> adamw: I escalated this bug for review
15:55:00 <maxamillion> I just always had the attitude of "if my system is broke, then I don't want to trust a potentially broken recovery"
15:55:25 <jlaska> adamw: but you are correct in that rescue-mode is not a typical operation.  My concern around shipping with a non-functioning rescue mode is that will limit our ability to debug problems "in the field"
15:55:51 <maxamillion> jlaska: ah, ok ... I see your point
15:56:17 <adamw> er, i don't? where's the problem with using a later or earlier rescue image? sorry if i'm being dumb :)
15:56:18 <jlaska> jgranados: alindebe: as our anaconda reps ... do you have any input on blocker status for 515091
15:56:44 <jlaska> adamw: you're not.  Something feels wrong about requiring media from another release/distro
15:57:05 <adamw> i dunno, to me this is equivalent to the 'we can fix it with an update after release' situation
15:57:07 <f13> especially if you've just bricked the one machine you have to /make/ isos
15:57:20 <jlaska> adamw: it's part of the media kit so you can't ship an update
15:57:25 <f13> and the only thing you have on hand to rescue it is the install media
15:57:30 <alindebe> jlaska: msivak said it should be fixed...
15:57:37 <adamw> if you're running alphas as the sole possible operating system on your one machine you should be shot, i really didn't think we were considering that a feasible scenario
15:57:40 <alindebe> (or will be in 12.8)
15:57:42 <f13> alindebe: the question is, what if it isn't fixed ?
15:57:46 <alindebe> Ah
15:57:48 <f13> is it something we should slip the release for?
15:58:09 <maxamillion> f13: that's actually a good point, I think the whole "having more than one machine" thing is something I take a bit for granted
15:58:11 <adamw> are we truly trying to cover the case where some numpty is sitting in front of a computer they must have working in an hour, with an f12 alpha CD and _nothing else_?!
15:58:34 <adamw> that sounds like final release criteria to me, not alpha :)
15:58:46 <notting> f13: final yes. beta, maybe. alpha, no?
15:58:46 <alindebe> I think I agree
15:58:47 <f13> adamw: given how few instances of very wide testing we get, having a functional rescue seems pretty important
15:59:02 <adamw> alindebe: with whom? :)
15:59:06 <alindebe> with you
15:59:11 <adamw> ah, thanks...hehe
15:59:16 <f13> but I do defer to anaconda folk.
15:59:21 <maxamillion> alindebe: just answer "yes" to questions like that ;)
15:59:27 <alindebe> haha, right
15:59:30 <jlaska> notting's assessment matches the install test plan acceptance criteria as well
15:59:43 <jlaska> Beta == tier#1 and tier#2 must PASS
15:59:47 <jlaska> Alpha == tier#1 must PASS
15:59:50 <alindebe> f13: I'm not really an authority on what should make or break a release date.
16:00:09 <jlaska> and rescue-mode is currently a tier#2 test
16:00:19 <alindebe> ...though I do take some credit for the delay in F11..
16:00:53 <jlaska> so consensus on this issue (which is currently MODIFIED) is to move to F12Beta?
16:00:54 <f13> jlaska: was that arrangement made before or after we renamed our milestones?
16:01:07 <alindebe> jlaska: So the question is really whether rescue mode should be in tier 1 or tier 2, then/
16:01:08 <alindebe> ?
16:01:09 <maxamillion> jlaska: then should it be bumped to Tier 1 or should we follow the current layout and mark this as not a beta blocker?
16:01:14 <maxamillion> errr alpha*
16:01:27 <jlaska> f13: I think about the same time
16:01:55 <adamw> i vote not a blocker.
16:02:05 <f13> still doesn't sit well with me given that rescue mode relies heavily on storage code, which should be in a testable state at our Alpha
16:03:12 <jlaska> the consensus here is not blocker
16:03:13 <maxamillion> alindebe: you beat me to it ... I just noticed :P
16:03:21 * maxamillion apparently can't multitask worth a darn
16:03:26 <jlaska> I agree with f13's comments, but I'm partial to a working installer
16:03:45 <jlaska> if this fix doesn't resolve the issue, we will need to work some sort of 'recommendation' for rescue-mode
16:03:58 <adamw> i dunno, me and alindebe on 'not-a-blocker', you and f13 on 'blocker', that's fairly even
16:04:06 <adamw> max gets the casting vote? :)
16:04:12 <maxamillion> oh crap
16:04:13 <jlaska> sorry, I've moved to not-a-blocker at this point
16:04:16 <adamw> ah ok
16:04:18 <f13> maybe we should revisit this argument if/when we get to an RC and find rescue still broken?
16:04:23 <jlaska> I'm going to put my votes on another issue later on I feel is more important
16:04:32 <jlaska> f13: I think that's fair
16:04:56 <jlaska> #agreed test fix for 515091 and revisit priority of this test if issue remains unresolved
16:05:15 <alindebe> f13, jlaska: I checked with pjones; he thinks beta is reasonable for rescue mode
16:05:22 <maxamillion> I was actually going to vote 'not-a-blocker' as well, I think if there are testing guidelines in place we should follow them, if the criteria of Tier 1 or Tier 2 needs to be altered in the future to satisfy concerns, then I think that should be handled outside of this meeting
16:05:42 <jlaska> ready to proceed to next issue?
16:05:47 <jlaska> 1 hour == 4 bugs
16:05:51 <jlaska> going to pick up the pace
16:05:59 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=515441
16:06:00 <buggbot> Bug 515441: high, low, ---, anaconda-maint-list, NEW, Can't select local CD/DVD after provide a wrong NFS location during install of F12 alpha
16:06:23 * notting would argue not an alpha blocker. please reboot and try again.
16:06:24 <f13> o_O
16:06:29 <f13> ditto
16:06:40 <mclasen> wrong user input doesn't sound like a blocker
16:06:44 <jlaska> I still need to get some additional information from Liam on this isse
16:06:47 <jlaska> issue
16:06:48 <maxamillion> +1
16:07:12 <jlaska> we've confirmed that nfs installations work (manual and kickstart) ... so there is something specific to his testing that we need to identify first
16:07:18 <notting> potentially not even a final release blocker (although worth fixing)
16:07:34 <jlaska> I agree, I will move to F12Blocker and we can reassess as more information comes in on this issue
16:07:36 <adamw> the initial description sounds something different from the summary
16:07:51 <adamw> but i can't quite follow what it's saying
16:08:10 <jlaska> adamw: agreed ... this issue needs an update to reflect current status
16:08:22 <jlaska> I can take an action item to review this
16:08:24 <alindebe> adamw: I find this to be a common problem >_<
16:08:39 <adamw> alindebe: hehe, you're not wrong =)
16:08:54 <jlaska> alindebe: if we've got docs folks need to be viewing before filing bugs, can you include those links?
16:09:03 <adamw> ok, i agree to jlaska reviews it, drop from list for now
16:09:14 <alindebe> jlaska: What do you  mean?
16:09:24 <jlaska> #agreed move 515441 to F12Blocker and reassess should new information come in
16:09:38 <adamw> i don't think this is a case of insufficient information exactly, just that the description doesn't quite...parse properly
16:09:38 <jlaska> #action jlaska to update description to match current status of 515441
16:09:44 <jlaska> adamw: okay
16:10:38 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=515472
16:10:40 <buggbot> Bug 515472: medium, low, ---, pjones, MODIFIED, f12 alpha system can not reboot
16:11:03 <jlaska> my understanding is this bug was preventing all installs from properly rebooting after install finished
16:11:22 <jlaska> f13: updated to not there are 2 issues at play
16:11:27 <jlaska> 1) an installed system cannot
16:11:28 <jlaska> reboot
16:11:31 <jlaska> 2) anaconda installs don't reboot.
16:11:37 <f13> it's also my understanding that both are fixed
16:11:50 <f13> but again we're blocked on verifying due to the sysfs_path bug
16:11:56 <jlaska> sweet, so I think we just need either your boot.iso or a new anaconda to test
16:11:59 <jlaska> f13: right on
16:12:21 <f13> need a new anaconda
16:12:28 <f13> my boot.iso doesn't get past disk bring up
16:12:37 <jlaska> #agreed 515472 - both reboot problems have fixes in and awaiting verification on new anaconda.
16:12:43 <jlaska> f13: good to know
16:13:00 <jlaska> I don't think there's anything more on this issue
16:13:24 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=515555
16:13:26 <buggbot> Bug 515555: high, low, ---, dwmw2, NEW, F-12-Alpha-TC - mkofboot doesn't return the proper exit code
16:13:45 <jlaska> This issue is preventing all ppc64 systems from properly rebooting after install on F-12-Alpha-TC
16:14:02 <jlaska> the problem is that mkofboot is not returning a proper exit code, a patch is available and tested.
16:14:37 <maxamillion> so we just waiting on verification of the patch?
16:14:44 <jlaska> I support this is a blocker for F-12-Alpha in that it's a test blocker for ppc64 platform
16:14:58 <f13> I feel much better about this being a blocker now that we have a fix posted
16:15:00 <jlaska> maxamillion: the patch is verified, if we agree on blocker status, we'd need a new package built, and tagged
16:15:10 <adamw> f13: heh, you cynic :)
16:15:11 <f13> I wasn't going to be too happy slipping the release while waiting for somebody to get around to caring about ppc64
16:15:18 <maxamillion> jlaska: ah
16:15:24 <notting> maxamillion: and building of said patch. if we can't find rrakus, we may want to find a willing provenpackager
16:15:38 <maxamillion> notting: oh :(
16:15:40 <adamw> but yeah, looks like not much required here except getting the fix built and allowing it in
16:16:15 <jlaska> are folks comfortable with this issue as a F-12-Alpha blocker?
16:16:36 <adamw> i agree with f13 :)
16:16:45 <f13> yeah, we'll have to get it built this morning to get into the rawhide re-try
16:16:53 <jlaska> okay
16:17:04 <jlaska> notting: can you take an action to hunt down someone to own building this?
16:17:09 <notting> working on it
16:17:12 <jlaska> thanks!
16:17:28 <jlaska> #action notting tracking down an owner to build a new yaboot for 515555
16:17:45 <f13> I bet jwb will build it for us
16:17:56 <jlaska> #agreed 515555 stays as a F-12-Alpha blocker.  Posted patch verified and awaiting package build+tag+compose
16:18:13 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=515564
16:18:14 <buggbot> Bug 515564: medium, low, ---, anaconda-maint-list, MODIFIED, Physical media installs fail - storage.errors.FSError: mountpoint does not exist
16:18:37 <jlaska> This issue was discovered while testing DVD installs on KVM and bare metal
16:18:53 <jlaska> at the end of install, it would stall at 100% package install
16:19:12 <jlaska> this also discovered a bug while attempting to display an exception dialog
16:19:23 <jlaska> bot are fixed in current anaconda git (included in anaconda-12.10 iirc)
16:19:35 <notting> jlaska: what's your kvm host? do you have the eject fix for that?
16:20:02 <adamw> definitely looks like a blocker.
16:20:36 <jlaska> notting: I unfortunately forget the details on this
16:20:52 <jlaska> notting: Either the eject fix resolved this one ... or this was a separate issue
16:20:55 <jlaska> I'd need clumens for details there
16:21:17 <jlaska> I recall testing an updates.img for clumens earlier in the week to work around this problem
16:21:27 <notting> there's a longstanding f11-ga f10-ga KVM bug where it lets you eject the DVD out from under anaconda. that was fixed in a qemu update
16:21:33 <jlaska> notting: aaah that one
16:21:36 <jlaska> yes I have the fix for that issue
16:21:44 <notting> ok then. carry on!
16:21:47 <jlaska> heh
16:21:57 <jlaska> okay ... I'm hearing no objections to alpha blocker
16:22:23 <f13> I think we could make a case if this was the very last bug we had to deal with
16:22:57 <jlaska> okay
16:23:05 <jlaska> #agreed 515564 remains as alpha-blocker.  Fix in and awaiting new anaconda for verification
16:23:18 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=515905
16:23:19 <buggbot> Bug 515905: medium, low, ---, anaconda-maint-list, NEW, f12 rawhide anaconda kickstart does not support NFS install
16:23:54 <f13> I think there is a patch posted for this
16:24:12 <f13> it needs to be reviewed
16:24:18 <f13> I didn't notice this as a blocker yesterday
16:24:27 <jlaska> I'm not clear on the exact reproducer yet for this issue.  However, clumens indicates that the error message is not satisfactory
16:25:19 <jlaska> I have positive test results for nfs installations and ks=nfs:// tests
16:25:50 <jlaska> but I'm not sure how Liam's test differs
16:26:16 <jlaska> aah
16:26:17 <f13> looks like he's doing ks=http  and having an nfs repo
16:26:26 <jlaska> I think this is specific to adding an nfs yum repo during stage#2
16:26:28 <f13> but I'm pretty sure I have that setup here with cobbler
16:26:48 <jlaska> yeah that's it ... we've discovered in test that the stage#2 repo edit dialog is basically non-functional
16:26:54 <jlaska> this and the next few bugs confirm
16:27:22 <adamw> so they should be duplicated?
16:27:23 <jlaska> so it depends whether the group feels that allowing manual edit of yum repositories during installation represents an Alpha blocker
16:27:37 <jlaska> adamw: possibly, I think they need triage first
16:27:48 <f13> defer to anaconda folks (which may be at lunch)
16:29:00 <jlaska> yeah, I think we need to follow-up with this later
16:29:15 <adamw> yeah, i don't think i feel qualified to venture an opinion
16:29:16 <jlaska> I'm not tied to this specific bug, but just an understanding on the state of the yum repo edit screen
16:29:29 <jlaska> isn't great in the Alpha
16:30:06 <jlaska> so leave it on, and discuss with them
16:30:10 <jlaska> or drop it, and discuss with them?
16:30:18 <jlaska> any preference?
16:30:39 <adamw> leave it and discuss
16:30:45 <jlaska> roger
16:30:50 <adamw> always safer as it stays on the list so we don't forget it later
16:31:16 <jlaska> #agreed 507093 - stay on F12Alpha and discuss state of yum repo edit dialogs with anaconda-devel
16:31:17 <f13> yeah
16:31:46 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=516042
16:31:48 <buggbot> Bug 516042: medium, low, ---, anaconda-maint-list, NEW, NFS installation does not work
16:32:22 <jlaska> I think this is the _same_ or similar
16:32:35 <adamw> i've seen that groundhog before!@
16:32:37 <jlaska> involves booting from DVD or boot.iso and adding an NFS yum repo
16:32:54 <jlaska> same action required here ... objections?
16:33:04 <adamw> nope
16:33:26 <jlaska> #agreed 516042 - stay on F12Alpha and discuss state of yum repo edit dialogs with anaconda-devel
16:33:45 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=516053
16:33:47 <buggbot> Bug 516053: medium, low, ---, anaconda-maint-list, NEW, NFS install dialog throws exception
16:34:12 <f13> seems related
16:34:22 * jlaska watching screencast
16:35:19 <jlaska> Great bug, but involves manual edit of existing repo and changing the repo type
16:35:30 <jlaska> I don't think this is a common operation, but I could be wrong
16:35:44 <adamw> that sounds like the one from liam actually
16:35:46 <jlaska> the good news though ... is this has been fixed already
16:35:59 <adamw> 515441
16:36:10 <adamw> the one where we couldn't quite follow the description
16:36:17 <jlaska> right
16:36:48 <jlaska> alindebe: commented that the exceptions are different
16:37:00 <jlaska> so I'm not going to DUP
16:37:19 <jlaska> but I think this falls into the same criteria used for 515441 ... I think we can move this out to F12Beta or F12Blocker
16:37:20 <adamw> oh yes.
16:37:24 <adamw> yep
16:37:39 <alindebe> (as a side note: Who attaches a MOVIE FILE to a bug report???)
16:37:45 <jlaska> alindebe: I love them!
16:37:46 <notting> yaboot built, if someone wants to file a tag request
16:39:12 <adamw> me too
16:39:17 <jlaska> okay ... moving to F12Beta for this
16:39:18 <adamw> all bugs should come with screencasts
16:39:22 <jlaska> objections/concerns?
16:39:34 <adamw> none
16:40:12 <jlaska> #agreed 516053 - involves manual edits of yum repo dialog, moved to F12Beta ... however, fix available in next anaconda build
16:40:13 <f13> alindebe: I've done it multiple times
16:40:24 <jlaska> almost there
16:40:26 <alindebe> huh.
16:40:30 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=516063
16:40:32 <buggbot> Bug 516063: medium, low, ---, anaconda-maint-list, NEW, HTTP installation source does not overwrite previous NFS source
16:40:34 <f13> alindebe: sometimes an ogg that captures what I was trying to do explains the issue far better than words
16:41:00 <alindebe> f13: I can understand that, but when it's only scrolling through a traceback... I'd prefer the *actual traceback*
16:41:42 <jlaska> this is another bug on the Yum repository edit dialog
16:41:52 <jlaska> which I think we know is non-functional or fragile for the Alpha
16:42:14 <jlaska> We don't have criteria in the plan around the yum dialogs, so we can discuss that for the future
16:42:49 <jlaska> I'll include this issue in the check-in with anaconda-devel this afternoon
16:43:01 <jlaska> alindebe: can you tell if all these bugs unique or are some DUPS?
16:43:34 <alindebe> I can't quite tell
16:43:48 <alindebe> the tracebacks are all distinct, but the reproducing seems similar
16:43:56 <jlaska> okay
16:44:31 <jlaska> appears this has already been dropped during the meeting by clumens
16:45:30 <jlaska> #agreed no action required - include in discussion w/ anaconda-devel on yum repo edit dialog status
16:45:35 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=516144
16:45:36 <buggbot> Bug 516144: medium, low, ---, jgranado, MODIFIED, Anaconda installing kernel-smp.ppc - expecting kernel.ppc64 kernel
16:45:53 <jlaska> This bug came out of the previous issue affecting all ppc64 systems
16:46:05 <jlaska> turns out anaconda is installing the incorrect kernel on all ppc64 platforms
16:46:20 <jlaska> A fix has been submitted and awaits a future build of anaconda for verification
16:46:29 <f13> yep
16:46:40 <jlaska> I requested this bug as I think this is also a test blocker for ppc64
16:47:01 <f13> IMHO if we made the previous yaboot bug a blocker, this one is too
16:47:03 <jlaska> if needed, the workaround would involve switching to tty2, chroot'ing and 'yum install kernel.ppc64'
16:47:05 <adamw> the f13 law applies - ppc bugs are blockers as long as they're fixed already :)
16:47:12 <jlaska> hehe
16:47:17 <jlaska> okay dokie
16:47:56 <jlaska> #agreed 516144 - consistent with f13 law ... blocks testing on ppc64 platform.  fixed in git already and awaiting build+tag
16:48:03 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=516168
16:48:04 <buggbot> Bug 516168: medium, medium, ---, hdegoede, MODIFIED, Traceback while initializing disks
16:48:56 <jlaska> f13: so this is the issue you discovered while testing your boot.iso
16:49:04 <jlaska> this is a testblocker for all installs, right?
16:49:22 <f13> yes
16:49:28 <jlaska> seems like a no brainer
16:49:29 <f13> it's a pretty major regression
16:49:39 <jlaska> an aside perhaps, but what introduced it?
16:49:46 <adamw> comment
16:49:47 * f13 had some choice words spewing out here in my office last night
16:49:51 <adamw> comment #3 is a pretty good explanation
16:50:00 <adamw> looks like a change in udev
16:50:08 <f13> it's a change in the /anaconda/ udev code
16:50:11 <jlaska> aah, more fallout from that
16:50:14 <adamw> code
16:50:20 <adamw> yeah sorry, lost a word there :)
16:50:30 <f13> there was lots of code shuffle that landed between 10.7 and 10.10
16:50:36 <f13> that never got tested since we were in a freeze
16:51:03 <f13> /why/ it landed while we were in a freeze and got bundled up with the freeze fixes we were looking for is a good discussion to have.
16:51:25 <adamw> agreed, but not in this meeting :)
16:51:33 <jlaska> #agreed 516168 - introduced by recent udev changes, blocks all installation.  Fix in git and awaiting build+compose+verification
16:51:45 <jlaska> okay, refreshing my list of bugs to see what I missed
16:52:31 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=515410
16:52:32 <buggbot> Bug 515410: medium, low, ---, anaconda-maint-list, NEW, f12 anaconda mouse was not initialized during installation on stage 2
16:52:53 <jlaska> so we reached critical mass on the unDUP'ing of this issue previously
16:53:10 <jlaska> I think this warrants blocker material, how do others feel?
16:53:33 <adamw> i do too, it's an interesting corner case though: it's a medium or even low severity bug that should be a blocker
16:53:46 <adamw> not to dwell on that too much, though - it needs fixin'
16:54:01 <jlaska> adamw: good point ... so it's more a visible polish issue that'll cause grief
16:54:40 <adamw> yeah
16:54:41 <jlaska> f13: notting: opinions?
16:54:56 <f13> there is a fix for the cursor
16:54:56 <adamw> it's, technically, strictly an aesthetic / usability issue: the pointer still exists and works. you just can't see it. :D
16:55:03 <notting> jlaska: is there no mouse cursor through the entirety of the install?
16:55:07 <f13> and without the mouse it's hard to know how to continue
16:55:16 <f13> notting: depends on if you get an error or not
16:55:18 <notting> f13: tab & f12. tab & f12
16:55:18 <jlaska> notting: it appears ... but we've not pinpointed the conditions that cause it to appear
16:55:21 <f13> I managed to get a cursor when I got a traceback.
16:55:26 <f13> notting: the average tester doesn't know that
16:55:43 * poelcat came across a few other bugs that might be worth considering... should I post them here or add to 'F12Alpha' ?
16:55:51 <f13> strike that, there is a /proposed/ fix for the cursor, which I think requires a new version of the theme in question
16:55:59 <f13> poelcat: here would be fine IMHO
16:56:08 <jlaska> poelcat: we can review those right after this bug
16:56:30 <adamw> poelcat: post them once we get through the list
16:56:39 * poelcat stands by :)
16:57:03 <notting> i'd lean towards blocker
16:57:54 <f13> I do too.  Even if people could continue, we'd see a firehose of bugs reported due to no cursor
16:58:02 <jlaska> agreed
16:58:46 <adamw> so, what action's needed here?
16:59:42 <jlaska> looking at just the bug ... we're still at the starting gate ... it's in NEW
16:59:52 <jlaska> f13 mentioned a potential fix being discussed
17:00:07 <adamw> why's it not in the bug report?
17:00:13 <f13> because it just got unduped
17:00:17 <jlaska> f13: should we reassign this bug to another component?
17:00:26 <f13> it was previously assumed to be part of the gtk theme not showing up on x86_64
17:00:56 <notting> yeah, it' s not that because then $otherthing would be broken
17:01:28 <jlaska> does someone want to take action on this bug to chase down an owner?
17:01:34 * jlaska not sure that anaconda is the right component
17:01:40 <f13> anaconda is
17:01:46 <f13> I can update the bug.
17:01:47 <adamw> f13: so you comment 11 on 513879 is for the cursor issue?
17:02:13 <f13> adamw: no.
17:02:19 <adamw> oh. :)
17:02:30 <f13> adamw: comment 11 on 513879 is for the missing gtk theme on x86_64
17:03:02 <f13> in the case of the missing gtk theme, the script that copies files around exited prematurely and we just simply didn't get some of the files we planned on
17:03:14 <f13> in the case of the missing cursor, we weren't even planning on getting the right files
17:03:36 <f13> the detection of what cursor files to get is done wrong, being accidentally correct in the past.
17:03:36 <adamw> right. just trying to make sure the appropriate discussions are on the appropriate reports
17:04:16 <jlaska> anything else to discuss on this issue?
17:04:39 <adamw> doesn't look like it - just it'd be nice for f13 to update 515410 with info on the proposed fix and its status
17:04:49 <f13> I just did.
17:04:54 <adamw> yay!
17:05:04 <f13> the fix hasn't been accepted though, so leaving the bug in NEW state
17:05:32 <jlaska> #agreed 515410 - results in no mouse cursor during installation.  Remains on F-12-Alpha,
17:06:03 <jlaska> I have to step out for a moment, can someone handle the topic updates to walk through poelcat's bz's?
17:06:12 <adamw> will do
17:06:15 <jlaska> thx
17:06:19 <jlaska> #chair adamw
17:06:21 <adamw> #topic proposed blockers
17:06:26 <poelcat> https://bugzilla.redhat.com/show_bug.cgi?id=515129
17:06:27 <adamw> poelcat, take it away :)
17:06:27 <poelcat> https://bugzilla.redhat.com/show_bug.cgi?id=505725
17:06:28 <buggbot> Bug 515129: medium, low, ---, hdegoede, ASSIGNED, Unable to use sata disks
17:06:29 <buggbot> Bug 505725: high, low, ---, anaconda-maint-list, NEW, Anaconda fails with exception while detecting storage
17:06:55 <adamw> first one sounds like a problem with the driver for his sata controller, i guess
17:07:31 <f13> poelcat: can we just go one at a time here?
17:07:57 <notting> hm
17:08:10 <notting> 515129, looks like all his disks got detected as raid members, but there was no raid set detected
17:08:17 <poelcat> f13: sorry, just those two
17:08:29 <f13> notting: raid as in mdraid or dmraid?
17:08:33 <notting> dmraid
17:08:40 <f13> dmraid
17:08:48 <adamw> storage.log says they're a BIOS RAID
17:08:52 <f13> yeah, so the user probably turned off dmraid in the bios, without deleting the raid array first
17:09:01 <f13> PEBCAK but hard to get right
17:09:25 <adamw> should we post a needinfo to confirm if that's the case?
17:09:37 <adamw> oops
17:09:44 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=515129
17:09:46 <buggbot> Bug 515129: medium, low, ---, hdegoede, ASSIGNED, Unable to use sata disks
17:09:55 <notting> f13: ideally, if we detect all disks as raid members, but no raid set, we have a better failure case
17:10:31 <f13> notting: I agree, but not for ALpha
17:10:40 * jlaska back
17:10:40 <f13> and I don't think this is an alpha blocker
17:10:59 <f13> adamw: yeah, that would be good
17:11:02 <adamw> i've added a needinfo
17:11:13 <adamw> i agree with it not being a blocker, if our diagnosis is correct, it's too specific a case
17:11:30 <f13> and the work around would be pretty easy
17:11:41 <f13> unless he took the disks out of a DMRAID system and tried to use them in a non-dmraid system
17:11:45 <f13> not sure what happens in that scenario
17:12:06 <notting> hm, no hans on #anaconda
17:12:16 <adamw> is there a drawback to displaying some kind of informational dialog in this situation and asking if the user wants to just wipe one or both disks?
17:14:28 <f13> adamw: there are many things that /could/ be done
17:14:35 <f13> however we shouldn't concern ourselves with them at this time
17:14:43 <adamw> ok, and we don't really need to discuss solutions here, you're right - sorry
17:14:50 <adamw> so let's go on to poelcat's next candidate
17:15:16 <adamw> #agreed 515129 is not a blocker. needinfo requested
17:15:26 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=505725
17:15:27 <buggbot> Bug 505725: high, low, ---, anaconda-maint-list, NEW, Anaconda fails with exception while detecting storage
17:16:36 <jlaska> FormatSetupError: invalid device specification
17:17:38 <f13> 11.5.0.59 was a while ago.
17:17:46 <adamw> yeah, that's like DAYS old :D
17:18:02 <jlaska> that's F11 GA right?
17:18:29 <f13> think so, preupgrade mentioned
17:18:41 <f13> upgrading from F10
17:18:43 <adamw> sergey does seem to imply it was still reproducible on at least july 23rd, though
17:18:50 <adamw> is clumens around to help discuss this?
17:18:56 <jlaska> he is now
17:19:04 <f13> jully 23rd with what media though?  F11 or rawhide?
17:19:21 <adamw> poin
17:19:22 <adamw> t
17:19:26 <notting> seems misfiled though - that exception report is from f11 anaconda
17:19:33 <f13> the dump is still from 11.5.0.59
17:19:38 <adamw> it was set to rawhide at the start
17:19:41 <adamw> i suspect a misfile
17:19:48 <jlaska> clumens: Howdy
17:19:54 <jlaska> clumens: talking about #topic bug
17:20:00 <f13> now, the problem /may/ still exist in rawhide, but we've got lots of different bits there
17:20:00 <adamw> clumens: we're on https://bugzilla.redhat.com/show_bug.cgi?id=505725 - is this an f11 report that's misfiled?
17:20:01 <buggbot> Bug 505725: high, low, ---, anaconda-maint-list, NEW, Anaconda fails with exception while detecting storage
17:21:26 <clumens> it's entirely possible the version detection got botched.
17:21:41 <clumens> i'd trust the anaconda version number in the dump over the version on the bug report.
17:21:52 <adamw> second question - is it likely this bug still exists in rawhide? or could you not guess?
17:22:55 <f13> hrm, but 515555 (yaboot) got closed, but its not tagged yet.
17:23:26 <adamw> i'd say re-open then, we need to be sure fixes are actually getting in
17:23:43 <clumens> i do not know, but it looks to me like the default swap from autopart on an LV did not get deleted.
17:24:02 <clumens> nobody's tested this as far as i know.
17:24:19 <jlaska> is this a common setup?
17:24:33 <jlaska> upgrading a system installed with F10 ... quite likely
17:24:44 <f13> but upgrading doesn't generally re-partition
17:24:52 <f13> I think there are two cases here
17:24:55 <alindebe> f13: afaik, it shouldn't ever..
17:25:02 <jlaska> f13: true sorry, meant installing on top of a system preeviously installed with F10
17:25:02 <f13> one is somebody upgrading, the other is somebody doing a fresh install
17:25:32 <f13> I don't think this is common enough to put as a blocker, particularly when we don't evne know if this is still happening in rawhide.
17:25:47 <adamw> yeah, on balance i agree
17:26:16 <adamw> i think we can just leave it under investigation for f11, presumably once it's precisely identified we'll know if it affects rawhide or not and can act as appropriate, i don't think we need to intervene here
17:27:13 <jlaska> no objections
17:27:41 <adamw> clumens, that sound ok to you?
17:28:06 <clumens> that's fine
17:28:24 <adamw> ok
17:28:41 <adamw> #agreed 505725 is not a blocker, no action required from us
17:28:51 <adamw> does anyone else have potential blockers to propose?
17:29:19 * jlaska starts the drumroll
17:29:48 * notting could look over all filed rawhide bugs, but is afraid to
17:29:53 <adamw> do we want to do f12beta and f12blocker or have we been going too long?
17:29:59 <notting> what's QA's opinion on the install matrix?
17:30:04 * adamw won't be able to as he has a doctor's appointment in 30 mins
17:30:20 <jlaska> adamw: no I think we'll save those for future
17:30:29 <jlaska> notting: definitely need a new anaconda build to get more green
17:30:42 <jlaska> I don't have a lot of data on ppc yet ... due to those 2 ppc64 issues
17:30:47 * adamw is out, gotta head off - back to jlaska
17:30:51 <jlaska> adamw: thanks!
17:31:06 <f13> jlaska: ppc32 installed "OK" with 12.7, but of course 12.10 is a killall
17:31:11 <jlaska> yeah :(
17:32:12 <jlaska> notting: so ppc64 looks good for alpha once past those 2 issues ... I'm not seeing any big issues lurking there
17:32:27 <f13> so we did pad our schedule a bit
17:32:42 <f13> there is possibility of getting a new compose out today, tested over the weekened/monday
17:32:50 <f13> and still making our release date
17:32:57 <f13> but if the RC is a dud, we're doomed
17:33:35 <jlaska> f13: yeah possible, I don't anticipate making a lot of headway on the matrix through the weekend
17:34:18 <f13> I might poke at it on Sunday
17:34:59 <notting> poelcat: 1800UTC is not 11AM EDT
17:35:00 <f13> notting: ping; what are your thoughts on an unsigned Alpha?
17:35:09 <jlaska> Liam and rhe can get started sunday evening (monday morning Beijing)
17:35:09 <f13> at least unsigned packages
17:35:24 <notting> f13: *shrug*?
17:35:25 <f13> but signed isos / repodata
17:35:27 <jlaska> I'm going to call the meeting folks, unless there are any alpha blocker bug topics
17:35:35 <poelcat> notting: lol ... good point
17:35:39 <f13> notting: I made a math error on how long it would take to sign with sigul, not 6 hours, 4 days
17:36:18 <f13> and since the key is known only to sigul, I can't use the old signing system to sign them quicker
17:36:23 <notting> f13: if we can't, we can't
17:36:31 <f13> k.  I'll put the key in a fedora-release today
17:36:42 <notting> f13: -> #devel
17:36:53 <jlaska> #endmeeting