15:00:07 #startmeeting F12 Alpha Blocker Review 15:00:26 jlaska: good day 15:00:34 #topic gathering 15:01:17 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 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 oh feh. no images today? 15:07:20 notting, hey guy, are you fine? 15:07:22 really? 15:07:29 jlaska: don't see them 15:07:37 * jlaska done a few rawhide installs today 15:07:45 from download.fedora.devel.redhat.com ... is it old content? 15:07:51 if so, Ithink we have a new blocker :) 15:07:52 maybe 15:07:53 notting: are you talking about isos or about ascii art ? 15:08:02 mclasen: boot.iso, etc. 15:08:31 hmm, I'm seeing them up on d.fedora.redhat.com 15:08:41 okay folks, let's get this show on the road 15:09:00 Let's start by walking down the F12Alpha list which has been getting some exercise this week 15:09:04 https://bugzilla.redhat.com/showdependencytree.cgi?id=507676&hide_resolved=1 15:09:22 #topic bug#499854 - https://bugzilla.redhat.com/show_bug.cgi?id=499854 15:09:28 Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=499854 high, low, ---, jgranado, MODIFIED, filedescriptor out of range in select() 15:09:28 Bug 499854: high, low, ---, jgranado, MODIFIED, filedescriptor out of range in select() 15:10:03 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 Clyde indicated the problem remains, I think that means we should bump this back to ASSIGNED 15:11:18 let me see if jgranados can join 15:11:48 jlaska: oh, nice. rawhide failed entirely. 15:11:53 head -> desk. 15:12:07 notting: I'll checkin shortly 15:12:09 * daMaestro lurks 15:12:15 jgranados: thanks for joining 15:12:24 we are talking about Clyde's latest update to 499854 15:12:34 based on his feedback, I'd like to move this back to ASSIGNED 15:12:35 * jgranados looks 15:14:00 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 and I believe it is blocking testing on the Alpha for Clyde 15:15:09 * maxamillion is here ... late, sorry ($dayjob) 15:15:21 maxamillion: hello 15:16:03 jlaska : hrm.. strange... 15:16:12 jlaska : I'll take a look. 15:17:08 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 any objections/alternatives? 15:17:17 jlaska : ok 15:17:22 jlaska : fine by me. 15:17:38 none here 15:18:16 #agreed Move 499854 to ASSIGNED, and reassess blocker potential after jgranados has had a chance to review 15:18:33 okay next up ... 15:18:43 #topic bug#512845 - https://bugzilla.redhat.com/show_bug.cgi?id=512845 15:18:46 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 Bug 512845: high, high, ---, stransky, ASSIGNED, setroubleshoot: SELinux is preventing firefox from changing a writable memory segment executable. 15:19:00 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 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 jlaska: got it 15:20:41 notting: you've got the last touch on this bug, do you have any updates? 15:20:51 no 15:20:56 * jlaska reading 15:21:12 somewhat confused why it would show up now, unless XR grew a JIT very recently 15:21:26 afaik ... this issue is keeping firefox from running in Enforcing mode? 15:21:34 on 32-bit x86 15:22:08 jlaska: yes 15:22:31 random side note that's related, was the SELinux+NM bug addressed already? 15:22:54 not sure ... but if you find that it wasn't, feel free to add to the list for review 15:23:05 jlaska : I have tested once more in my environment and I can't see 499854. 15:23:10 is clyde here? 15:23:13 he is not 15:23:30 jgranados: not sure if remote access to his system is an option 15:24:03 firefox not starting with a default install seems like a valid blocker on the alpha 15:24:15 but it's not clear what the next course of action is for this issue 15:24:21 i just had to grab the updated xulrunner and firefox from koji 15:24:36 notting: are there particular people that we should pull in on this? 15:25:05 get caillon/stransky/jhorak on the line and see if they can disable the jit in the meantime? 15:25:05 Alticon-Brian: is this fixed in the latest xulrunner/firefox in koji? 15:25:12 well, it 15:25:16 * jlaska goes to find them 15:25:29 http://koji.fedoraproject.org/koji/buildinfo?buildID=126008 15:25:33 there's xulrunner at least 15:25:39 firefox starts 15:25:43 Alticon-Brian: that resolved the problem for you? 15:25:44 but has the same old selinux errors again 15:26:40 so i just chcon the firefox directory 15:26:45 and everything plays nicely again 15:26:48 okay, I'm not finding any of them online at the moment 15:27:00 :( 15:27:05 anyone want to take an action to follow-up with them? 15:27:42 #action follow-up with caillon/stransky/jhorak to disable the jit for Alpha 15:27:47 I can ping them on it, I'll shoot out an email to f-d-l I guess 15:27:58 maxamillion: thanks! 15:28:00 hrm. 15:28:14 that way we might even get some others to chime in 15:28:15 f13: ? 15:28:26 seems I forgot to put this new blocker day in my calendar 15:28:56 maxamillion: blocker review day. This one didn't exist a couple weeks ago 15:29:16 #agreed reach out to caillon/stransky/jhorak for input on disabling jit in F-12-Alpha firefox ... remain as a blocker 15:29:17 f13: ohhhh, I dunno ... just saw the email yesterday 15:29:29 okay ... next up ... 15:29:35 jlaska : another question is, did Clyde get passed 516168? 15:29:44 #topic https://bugzilla.redhat.com/show_bug.cgi?id=513879 15:29:46 Bug 513879: medium, low, ---, katzj, MODIFIED, Rawhide anaconda not using correct gtk theme 15:29:50 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 jlaska: is it worth slipping the release for? 15:30:08 513879 is fixed upstream. 15:30:16 I confirmed the fix (well I made the fix) 15:30:25 lol 15:30:29 f13: firefox not working out of the box is a tough one 15:30:29 we don't have a build with that fix in rawhide because the build with that fix regressed in other ways 15:30:41 jlaska: it's only not working out of the box for i386 people with selinux enabled 15:30:48 and thats if they don't do any of the 0-day updates 15:31:28 f13: I'd like to hear back from the maintainers on this ... but having a workaround is definitely a positive 15:31:41 f13: can you post the steps you did to workaround the issue in the bz? 15:31:49 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 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 maxamillion: it'd be close, depends on how long it takes for those packages to build. 15:32:42 (and how late I stay up to compose the RC) 15:33:05 jlaska: i'm not sure booting with selinux permissive is a workaround we want to push 15:33:11 I agree 15:33:18 not for firefox 15:33:22 morning 15:33:23 f13: rgr 15:33:25 it's a workaround until you install the updates 15:33:25 adamw: hi hi 15:33:28 f13: hm, maybe discuss scheduling after we get through the list? might be a moot discussion by that point. 15:33:29 sorry, guys, my alarm didn't go off 15:33:36 it's not like people are going to install Alpha and then not update it for the next 6 months. 15:33:45 notting: thanks yes. .. for now we are just reviewing the bugs for blocker material 15:33:47 f13: true 15:34:06 where are we? 15:34:18 adamw: arguing about what a blocker is :) 15:34:20 we've moved back to previous topic as f13 has concerns 15:34:31 bug#512845 15:34:32 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 I'm happy to re-visit after the rest of the list 15:34:50 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 because iirc provenpackagers can commit to anything not explicitly excluding them, right? 15:35:35 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 maxamillion: a) ff/xr is special. b) it's not at all clear if it's a 'simple' patche 15:35:49 maxamillion: patches to firefox are a touchy subject, as the trademark comes into play 15:35:56 so, firefox doesn't work with selinux enabled on x86-32 15:35:58 f13: ahhh, gotchya 15:36:08 adamw: or permissive 15:36:13 erk 15:36:48 jlaska: fair enough 15:36:57 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 should we move the topic of the fix to #fedora-devel after this meeting is over? 15:37:26 adamw: that's where my concern on this issue comes from 15:37:47 maxamillion: yeah, that might be appropriate 15:37:48 adamw: the idea being that we'd have it fixed in rawhide by the time Alpha is publicly released 15:37:59 so if people update before launching the browser.... 15:38:13 :/ 15:38:27 I don't think many will though 15:38:30 ermm, that's rough 15:38:33 * poelcat thinks we can't predict that 15:38:57 so let's take score so we can move on 15:39:02 yeah, my feeling is that's not likely 15:39:02 most people install and then want to _try_ the thing, and firefox is probably one of the first things they run. 15:39:42 adamw: agreed 15:40:00 then should FF be added to the critical path? 15:40:03 (is it there already?) 15:40:13 * poelcat votes for moving on and circling back 15:40:29 #idea f13 asks ... should firefox be added to critical path 15:40:34 f13: we can come back to that 15:41:35 I think the consensus is to keep this on the list, and f13 introduces a valid recovery plan if needed 15:42:18 folks ready to move on to #topic bug? 15:42:39 yes 15:42:52 f13: sorry, i broke it 15:42:58 and f13 fixed it! 15:43:22 so it's in MODIFIED and awaiting tagging+compose is that accurate? 15:43:29 sortof 15:43:35 (working build)+ tag + compose 15:43:42 we're waiting for further anaconda fixes before tagging and composing 15:43:49 so it's blocked by newer bugs 15:43:57 right on ... I see a few other ones coming up :) 15:44:13 any additional action needed here, or just wait for verification when possible? 15:44:58 just wait really. 15:45:06 there may be more fixes in this area to get the X cursor right 15:45:38 #agreed 513879 in MODIFIED and awaiting verification once tagged and composed for the Alpha 15:45:48 #topic https://bugzilla.redhat.com/show_bug.cgi?id=515091 15:45:49 Bug 515091: medium, low, ---, msivak, MODIFIED, rescue mode fails: not all arguments converted; open("/etc/mtab", ... 15:46:01 sorry, one second 15:46:11 when we talk about 513879, _which_ bug are we talking about? 15:46:20 ah good question 15:46:25 the wrong GTK theme or the cursor issue? 15:46:31 cos i'm afraid i still don't think they're duplicates :) 15:46:33 wrong GTK theme 15:46:37 cursor one is different 15:46:44 f13: not so far as bugzilla's concerned 15:46:46 (since they are different themes) 15:46:51 f13: cursor issue has been marked as a dupe of this bug 15:46:58 f13: can that fix be confirmed with your boot.iso? 15:46:58 there is a gtk theme, an icon theme, and a cursor theme 15:47:06 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 Bug 515410: medium, low, ---, anaconda-maint-list, CLOSED DUPLICATE, f12 anaconda mouse was not initialized during installation on stage 2 15:47:11 adamw: it's not, it needs to be unduped and put on the blocker list 15:47:36 jlaska: "that fix" ? 15:47:45 that was my belief and jlaska's too, i think all three of us outvote andy...i'm de-duping it 15:47:53 adamw: thanks 15:48:09 the reasons for the breakage are vastly different too 15:48:09 f13: is the fix for 513879 included in that boot.iso you posted to anaconda-devel-list? 15:48:20 jlaska: yes, the fix for the gtk theme 15:48:58 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 adamw: we can add that UNDUP'D issue to the end of the list 15:49:05 ok, i de-duped 515410 and marked it blocking alpha 15:49:14 jlaska: yup, throw it on there 15:49:15 the missing cursor is due to improper discovery of the cursor theme 15:49:55 okay, let's move on 15:50:08 I'm using my boot.iso to test rescue mode 15:50:41 and it tracebacks with the same thing regular installs do 15:50:57 so testing of this is blocked by 516168 15:51:20 i'm with jlaska on this one, i don't think it's really an alpha blocker 15:51:40 adamw: for 515091? 15:51:43 rescue not a blocker? 15:51:57 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 jlaska: f13: yes 15:52:16 adamw: it doesn't meet the bar we've established in that it is a tier#2 test 15:52:19 can't you use a stable liveCD for rescue purposes? 15:52:24 adamw: unless your hardware doesn't work with older media 15:52:36 however, I think it's worth considering as rescue-mode is your only recovery/debugging option when installation goes south 15:53:03 the anaconda team should probably chime in as to whether or not they consider rescue mode to be blocker worthy 15:53:06 '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 blocker/slip worthy 15:53:08 jlaska: link handy for tier#1 and #2 tests? 15:53:18 https://fedoraproject.org/wiki/QA:Fedora_12_Alpha_Install_Test_Results 15:53:42 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 the main reason I bring it up is because I always have a stable liveCD handy when playing around with rawhide 15:54:52 adamw: I escalated this bug for review 15:55:00 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 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 jlaska: ah, ok ... I see your point 15:56:17 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 jgranados: alindebe: as our anaconda reps ... do you have any input on blocker status for 515091 15:56:44 adamw: you're not. Something feels wrong about requiring media from another release/distro 15:57:05 i dunno, to me this is equivalent to the 'we can fix it with an update after release' situation 15:57:07 especially if you've just bricked the one machine you have to /make/ isos 15:57:20 adamw: it's part of the media kit so you can't ship an update 15:57:25 and the only thing you have on hand to rescue it is the install media 15:57:30 jlaska: msivak said it should be fixed... 15:57:37 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 (or will be in 12.8) 15:57:42 alindebe: the question is, what if it isn't fixed ? 15:57:46 Ah 15:57:48 is it something we should slip the release for? 15:58:09 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 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 that sounds like final release criteria to me, not alpha :) 15:58:46 f13: final yes. beta, maybe. alpha, no? 15:58:46 I think I agree 15:58:47 adamw: given how few instances of very wide testing we get, having a functional rescue seems pretty important 15:59:02 alindebe: with whom? :) 15:59:06 with you 15:59:11 ah, thanks...hehe 15:59:16 but I do defer to anaconda folk. 15:59:21 alindebe: just answer "yes" to questions like that ;) 15:59:27 haha, right 15:59:30 notting's assessment matches the install test plan acceptance criteria as well 15:59:43 Beta == tier#1 and tier#2 must PASS 15:59:47 Alpha == tier#1 must PASS 15:59:50 f13: I'm not really an authority on what should make or break a release date. 16:00:09 and rescue-mode is currently a tier#2 test 16:00:19 ...though I do take some credit for the delay in F11.. 16:00:53 so consensus on this issue (which is currently MODIFIED) is to move to F12Beta? 16:00:54 jlaska: was that arrangement made before or after we renamed our milestones? 16:01:07 jlaska: So the question is really whether rescue mode should be in tier 1 or tier 2, then/ 16:01:08 ? 16:01:09 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 errr alpha* 16:01:27 f13: I think about the same time 16:01:55 i vote not a blocker. 16:02:05 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 the consensus here is not blocker 16:03:13 alindebe: you beat me to it ... I just noticed :P 16:03:21 * maxamillion apparently can't multitask worth a darn 16:03:26 I agree with f13's comments, but I'm partial to a working installer 16:03:45 if this fix doesn't resolve the issue, we will need to work some sort of 'recommendation' for rescue-mode 16:03:58 i dunno, me and alindebe on 'not-a-blocker', you and f13 on 'blocker', that's fairly even 16:04:06 max gets the casting vote? :) 16:04:12 oh crap 16:04:13 sorry, I've moved to not-a-blocker at this point 16:04:16 ah ok 16:04:18 maybe we should revisit this argument if/when we get to an RC and find rescue still broken? 16:04:23 I'm going to put my votes on another issue later on I feel is more important 16:04:32 f13: I think that's fair 16:04:56 #agreed test fix for 515091 and revisit priority of this test if issue remains unresolved 16:05:15 f13, jlaska: I checked with pjones; he thinks beta is reasonable for rescue mode 16:05:22 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 ready to proceed to next issue? 16:05:47 1 hour == 4 bugs 16:05:51 going to pick up the pace 16:05:59 #topic https://bugzilla.redhat.com/show_bug.cgi?id=515441 16:06:00 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 o_O 16:06:29 ditto 16:06:40 wrong user input doesn't sound like a blocker 16:06:44 I still need to get some additional information from Liam on this isse 16:06:47 issue 16:06:48 +1 16:07:12 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 potentially not even a final release blocker (although worth fixing) 16:07:34 I agree, I will move to F12Blocker and we can reassess as more information comes in on this issue 16:07:36 the initial description sounds something different from the summary 16:07:51 but i can't quite follow what it's saying 16:08:10 adamw: agreed ... this issue needs an update to reflect current status 16:08:22 I can take an action item to review this 16:08:24 adamw: I find this to be a common problem >_< 16:08:39 alindebe: hehe, you're not wrong =) 16:08:54 alindebe: if we've got docs folks need to be viewing before filing bugs, can you include those links? 16:09:03 ok, i agree to jlaska reviews it, drop from list for now 16:09:14 jlaska: What do you mean? 16:09:24 #agreed move 515441 to F12Blocker and reassess should new information come in 16:09:38 i don't think this is a case of insufficient information exactly, just that the description doesn't quite...parse properly 16:09:38 #action jlaska to update description to match current status of 515441 16:09:44 adamw: okay 16:10:38 #topic https://bugzilla.redhat.com/show_bug.cgi?id=515472 16:10:40 Bug 515472: medium, low, ---, pjones, MODIFIED, f12 alpha system can not reboot 16:11:03 my understanding is this bug was preventing all installs from properly rebooting after install finished 16:11:22 f13: updated to not there are 2 issues at play 16:11:27 1) an installed system cannot 16:11:28 reboot 16:11:31 2) anaconda installs don't reboot. 16:11:37 it's also my understanding that both are fixed 16:11:50 but again we're blocked on verifying due to the sysfs_path bug 16:11:56 sweet, so I think we just need either your boot.iso or a new anaconda to test 16:11:59 f13: right on 16:12:21 need a new anaconda 16:12:28 my boot.iso doesn't get past disk bring up 16:12:37 #agreed 515472 - both reboot problems have fixes in and awaiting verification on new anaconda. 16:12:43 f13: good to know 16:13:00 I don't think there's anything more on this issue 16:13:24 #topic https://bugzilla.redhat.com/show_bug.cgi?id=515555 16:13:26 Bug 515555: high, low, ---, dwmw2, NEW, F-12-Alpha-TC - mkofboot doesn't return the proper exit code 16:13:45 This issue is preventing all ppc64 systems from properly rebooting after install on F-12-Alpha-TC 16:14:02 the problem is that mkofboot is not returning a proper exit code, a patch is available and tested. 16:14:37 so we just waiting on verification of the patch? 16:14:44 I support this is a blocker for F-12-Alpha in that it's a test blocker for ppc64 platform 16:14:58 I feel much better about this being a blocker now that we have a fix posted 16:15:00 maxamillion: the patch is verified, if we agree on blocker status, we'd need a new package built, and tagged 16:15:10 f13: heh, you cynic :) 16:15:11 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 jlaska: ah 16:15:24 maxamillion: and building of said patch. if we can't find rrakus, we may want to find a willing provenpackager 16:15:38 notting: oh :( 16:15:40 but yeah, looks like not much required here except getting the fix built and allowing it in 16:16:15 are folks comfortable with this issue as a F-12-Alpha blocker? 16:16:36 i agree with f13 :) 16:16:45 yeah, we'll have to get it built this morning to get into the rawhide re-try 16:16:53 okay 16:17:04 notting: can you take an action to hunt down someone to own building this? 16:17:09 working on it 16:17:12 thanks! 16:17:28 #action notting tracking down an owner to build a new yaboot for 515555 16:17:45 I bet jwb will build it for us 16:17:56 #agreed 515555 stays as a F-12-Alpha blocker. Posted patch verified and awaiting package build+tag+compose 16:18:13 #topic https://bugzilla.redhat.com/show_bug.cgi?id=515564 16:18:14 Bug 515564: medium, low, ---, anaconda-maint-list, MODIFIED, Physical media installs fail - storage.errors.FSError: mountpoint does not exist 16:18:37 This issue was discovered while testing DVD installs on KVM and bare metal 16:18:53 at the end of install, it would stall at 100% package install 16:19:12 this also discovered a bug while attempting to display an exception dialog 16:19:23 bot are fixed in current anaconda git (included in anaconda-12.10 iirc) 16:19:35 jlaska: what's your kvm host? do you have the eject fix for that? 16:20:02 definitely looks like a blocker. 16:20:36 notting: I unfortunately forget the details on this 16:20:52 notting: Either the eject fix resolved this one ... or this was a separate issue 16:20:55 I'd need clumens for details there 16:21:17 I recall testing an updates.img for clumens earlier in the week to work around this problem 16:21:27 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 notting: aaah that one 16:21:36 yes I have the fix for that issue 16:21:44 ok then. carry on! 16:21:47 heh 16:21:57 okay ... I'm hearing no objections to alpha blocker 16:22:23 I think we could make a case if this was the very last bug we had to deal with 16:22:57 okay 16:23:05 #agreed 515564 remains as alpha-blocker. Fix in and awaiting new anaconda for verification 16:23:18 #topic https://bugzilla.redhat.com/show_bug.cgi?id=515905 16:23:19 Bug 515905: medium, low, ---, anaconda-maint-list, NEW, f12 rawhide anaconda kickstart does not support NFS install 16:23:54 I think there is a patch posted for this 16:24:12 it needs to be reviewed 16:24:18 I didn't notice this as a blocker yesterday 16:24:27 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 I have positive test results for nfs installations and ks=nfs:// tests 16:25:50 but I'm not sure how Liam's test differs 16:26:16 aah 16:26:17 looks like he's doing ks=http and having an nfs repo 16:26:26 I think this is specific to adding an nfs yum repo during stage#2 16:26:28 but I'm pretty sure I have that setup here with cobbler 16:26:48 yeah that's it ... we've discovered in test that the stage#2 repo edit dialog is basically non-functional 16:26:54 this and the next few bugs confirm 16:27:22 so they should be duplicated? 16:27:23 so it depends whether the group feels that allowing manual edit of yum repositories during installation represents an Alpha blocker 16:27:37 adamw: possibly, I think they need triage first 16:27:48 defer to anaconda folks (which may be at lunch) 16:29:00 yeah, I think we need to follow-up with this later 16:29:15 yeah, i don't think i feel qualified to venture an opinion 16:29:16 I'm not tied to this specific bug, but just an understanding on the state of the yum repo edit screen 16:29:29 isn't great in the Alpha 16:30:06 so leave it on, and discuss with them 16:30:10 or drop it, and discuss with them? 16:30:18 any preference? 16:30:39 leave it and discuss 16:30:45 roger 16:30:50 always safer as it stays on the list so we don't forget it later 16:31:16 #agreed 507093 - stay on F12Alpha and discuss state of yum repo edit dialogs with anaconda-devel 16:31:17 yeah 16:31:46 #topic https://bugzilla.redhat.com/show_bug.cgi?id=516042 16:31:48 Bug 516042: medium, low, ---, anaconda-maint-list, NEW, NFS installation does not work 16:32:22 I think this is the _same_ or similar 16:32:35 i've seen that groundhog before!@ 16:32:37 involves booting from DVD or boot.iso and adding an NFS yum repo 16:32:54 same action required here ... objections? 16:33:04 nope 16:33:26 #agreed 516042 - stay on F12Alpha and discuss state of yum repo edit dialogs with anaconda-devel 16:33:45 #topic https://bugzilla.redhat.com/show_bug.cgi?id=516053 16:33:47