16:09:54 #startmeeting F-14-Final Blocker Review Meeting - https://bugzilla.redhat.com/showdependencytree.cgi?id=F14Blocker&hide_resolved=1 16:09:54 Meeting started Mon Oct 18 16:09:54 2010 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:09:54 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:10:18 Maybe I should mention it now since it affects the minutes: 16:10:23 Okay everyone, thanks to clumens for the reminder, we have another blocker review scheduled for today to wrap things up prior to the RC 16:10:48 Could you put bug summaries in the minutes somewhere? It would make the meeting summary email a lot more useful. 16:11:00 we do that now 16:11:20 You didn't last time. Hence my request. If you will then thanks. 16:11:20 yo 16:11:22 the topics just have the bug, not the title. 16:11:35 right ... we post #info and #action and #agreed where possible 16:11:53 http://meetbot.fedoraproject.org/teams/f-14-blocker-review/f-14-blocker-review.2010-10-01-16.00.html 16:12:01 I'd like to not re-hash content that lives in the bug, but if there are specifics that you want to add to a bug, feel free to use #info 16:12:01 Right, but that doesn't include the bug title. Just bug numbers in the title isn't that helpful. 16:12:03 if you could add the bug title to the #topics. 16:12:08 that would be nice. 16:12:12 ^ that 16:12:26 alright, I'll do that 16:12:30 Thanks 16:12:49 waiting for more folks to join ... say hi to the logs ... 16:13:00 hi! :-) 16:13:37 saccia: welcome 16:13:43 I see nirik, gholms|work ... 16:13:53 clumens: notting: Oxf13: adamw 16:13:56 anyone else? 16:14:05 it'sa me 16:14:07 * red_alert 16:14:25 hi red_alert 16:14:40 hi :) 16:15:38 alright, let's get started 16:15:44 see #topic for the URL I'll be working from 16:16:20 #topic https://bugzilla.redhat.com/show_bug.cgi?id=583906 - Backtrace in clearpart_gui when only uninitialized disks are found 16:16:22 Bug 583906: medium, low, ---, hdegoede, ASSIGNED, Backtrace in clearpart_gui when only uninitialized disks are found 16:17:07 looks like bcl and Hans replied in this issue since last meeting 16:17:18 we have a proposed patch (https://bugzilla.redhat.com/attachment.cgi?id=453762&action=diff) 16:17:33 clumens: bcl: has this been reviewed and accepted for the next installer build? 16:17:42 * clumens checks 16:18:33 * jlaska notes that based on feedback from the reporter, this is specific to BIOS RAID + Live install 16:18:33 the proposed patch does solve some issue, but not the actually reported issue 16:18:45 jlaska: committed but not built 16:19:01 so the reported bug is still present 16:19:03 clumens: bcl: what do you guys think about the latest feedback in the bug? 16:19:36 adamw: seems so, but this time it's specific to live installer I believe 16:19:47 jlaska: from talking on friday, i think we all agreed that the traceback was certainly worth fixing, but it's unsure whether we can deal with the other problem. 16:19:55 also i haven't had time to look at the latest 16:20:41 so I guess our first question ... does this meeting blocker criteria? 16:21:07 we don't currently distinguish partitioning issues between the live and media installs, 16:21:11 so I think this is covered by ... 16:21:13 "# The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above " 16:21:46 I believe an exception would work if there was a reasonable workaround for this issue 16:22:05 telling someone who's just downloaded one disc to go download another does kinda suck 16:22:11 clumens: bcl: who has the ball on this, are you guys continuing to work the issue with the reporter? Is there more feedback that you need? 16:22:19 adamw: certainly not ideal, no 16:22:38 I'll test the live installer on my BIOS RAID setup after this 16:22:39 re-syncing brain... 16:22:54 #action jlaska - retest BIOS RAID installs using Live image 16:23:43 jlaska: test, its on f14-branch, the specific issue the last reporter had is likely a different issue (his RAID isn't showing up as a device) 16:24:14 But the problem with no installable disks is fixed, it now display's the dialog if all disks are hidden. 16:24:21 bcl: so the traceback is resolved, and we should move the remaining problem into a new bug? 16:24:22 bcl: just in case - 'last reporter' is red_alert 16:24:36 and red_alert is here if feedback is needed 16:25:02 bcl and I had some good IRC communication last Friday over this already :) 16:25:25 right. He's added lsmod output, which I looked at, and didn't see anything obvious. He reported that DVD works, so its limit to livecd 16:25:56 I'll test live install on my BIOS RAID setup (and I can ask for more feedback from others with BIOS RAID) 16:25:59 we did have problems with live image activating raid arrays and stuff before 16:25:59 yes, I think the RAID not showing as a device is a separate bug. 16:26:15 hans probably remembers more of the details, he'd be a good guy to check with on this one 16:26:25 yep 16:26:41 while unfortunate, but if it turns out this is specific to a single setup/device, I think we need to consider moving it off the list 16:26:51 yeah, let's wait till we have more testing though 16:26:53 but we'll need test feedback from other setups to confirm 16:26:56 yup 16:27:01 alright, so ... let's summarize 16:27:17 red_alert: do you want to file a new bug for your BIOS RAID device not showing up in live installer? 16:27:39 bcl: clumens: anything else you guys can do on this issue? 16:28:09 jlaska: can do if it helps 16:28:19 red_alert: yes please, I believe that was consensus so far 16:28:46 given the current data, I don't think so. It needs to be narrowed down to see if it is a general issue or specific HW 16:28:53 proposed #agreed 583906 - original traceback has been resolved with patch, remaining missing BIOS RAID drive(s) will be tracked in a new bug 16:29:13 i posted my one suggestion in the bug 16:29:21 proposed #action anyone with BIOS RAID, please help test BIOS RAID installs from Live image (583906) 16:29:25 ack/nak/patch? 16:29:35 ack 16:29:55 oh, the bios raid is showing up in the specialized storage tab, btw...but clicking next gives no disks found - just to be precise here :) 16:29:58 red_alert: another test request from clumens for you in the bug 16:30:06 red_alert: aah, that's expected 16:30:36 red_alert: so even if you select BIOS raid under 'specialized storage', it's showing 'no disks found'? 16:30:51 I'll perform clumens latest suggestion just after the meeting 16:30:54 thanks 16:30:57 any other ack/nak? 16:31:32 alright, going with it 16:31:34 #agreed 583906 - original traceback has been resolved with patch, remaining missing BIOS RAID drive(s) will be tracked in a new bug 16:31:49 i don't necessarily think that'll work. but it's worth a shot. 16:31:52 #action fedora-qa - with BIOS RAID, please help test BIOS RAID installs from Live image (583906) 16:31:52 jlaska: right, I go to the specialized storage, see and enable the raid bios and going further I'm shown some message about sd{a,b,c,d} and traceback or with the patch "no disks found" 16:32:02 red_alert: okay, thanks 16:32:18 before moving on ... 16:32:22 do we want to include ON_QA bugs? 16:32:33 * jlaska votes for no ... since I'll send those to test@ in a different email 16:32:59 nope, just note we should test and push them asap 16:33:23 okay, so next NEW || ASSIGNED || MODIFIED bug is ... 16:33:41 does a ON_QA have negative feedback, though? 16:33:42 #topic https://bugzilla.redhat.com/show_bug.cgi?id=584328 - AttributeError: 'NoneType' object has no attribute 'name' 16:33:43 Bug 584328: medium, low, ---, dlehman, MODIFIED, AttributeError: 'NoneType' object has no attribute 'name' 16:33:56 want to guess again? :) 16:34:02 red_alert: if so, it should be moved to ASSIGNED 16:34:05 adamw: ? 16:34:22 Fixed In Version: python-pyblock-0.51-1.fc14 16:34:31 oh i see, you're including MODIFIED 16:34:36 yes 16:34:44 until they're in bodhi, I'm including them 16:34:47 so we need the new pyblock to be submitted 16:34:51 yeah 16:35:27 who owns that? clumens: bcl: do you know if pjones is planning to do that? 16:36:16 #info Waiting on new pyblock to be submitted 16:36:36 it's assigned to dlehman, who is out today, so I think we'll need someone else to cover this 16:36:53 jlaska: pjones usually does pyblock builds 16:37:09 okay 16:37:33 proposed #action pjones - will submit updated pyblock build for 584328 16:37:44 ack/nak/patch? 16:37:58 http://koji.fedoraproject.org/koji/buildinfo?buildID=200680 16:38:19 we need a bodhi submission too 16:38:46 clumens: do you mind coordinate with pjones after this? 16:38:52 briefly 16:39:02 hah, okay thanks! 16:39:15 #action pjones - will submit updated pyblock build for 584328 16:39:25 next related bug ... 16:39:44 #topic https://bugzilla.redhat.com/show_bug.cgi?id=641474 - devicemapper UUID field cannot be assigned after map creation 16:39:45 Bug 641474: medium, high, ---, agk, MODIFIED, libdm does not present method to assign UUID after map creation 16:39:55 "kernel-2.6.35.6-43.fc14 has been pushed to the Fedora 14 stable repository. If 16:39:59 problems still persist, please make note of it in this bug report." 16:40:09 sure enough ... https://admin.fedoraproject.org/updates/kernel-2.6.35.6-43.fc14 16:40:13 so I'll move this to ON_QA 16:40:23 and we'll need testing once RC1 is out 16:40:25 yup 16:40:33 well, bodhi should move this to ON_QA 16:40:37 since the bug is linked 16:40:43 either way 16:41:19 proposed #agreed 641474 - Fix included in https://admin.fedoraproject.org/updates/kernel-2.6.35.6-43.fc14, move to ON_QA and request testing 16:41:59 if the bug was properly linked it'd be closed by now, since the update is pushed stable 16:42:04 so obviously it isn't 16:42:13 maybe it was added late, dunno 16:42:25 anyway, moved to ON_QA 16:42:29 ack/nak/patch? 16:42:55 ack 16:43:13 any other non-qa votes? 16:43:48 okay, moving on 16:43:52 #agreed 641474 - Fix included in https://admin.fedoraproject.org/updates/kernel-2.6.35.6-43.fc14, move to ON_QA and request testing 16:44:11 oh I see, I got my bugs crossed 16:44:23 the kernel update was linked to the next issue 16:44:45 you suck 16:44:59 I'll note that in your next review :) 16:45:11 so, let's see, it's libdm for 641474, right? 16:45:17 yeah ... one sec, lemme play topic bingo 16:45:33 #topic https://bugzilla.redhat.com/show_bug.cgi?id=641474 - libdm does not present method to assign UUID after map creation 16:45:34 Bug 641474: medium, high, ---, agk, MODIFIED, libdm does not present method to assign UUID after map creation 16:45:45 you never actually changed the topic :) 16:45:57 you sure ? :) 16:46:07 the bz stayed the same, the description now matches the bug 16:46:42 the previous #topic was *actually* for 641476 16:46:48 oh, ok 16:46:56 apologies for confusion 16:47:10 okay ... so I have no idea where this issue is? 16:47:25 we left it on Friday with pjones working on the batch of updates 16:47:38 Its one of the bugs related to the previous one. 16:47:43 right on 16:47:55 are we waiting on a bodhi update for this? 16:49:03 i just commented in the bug that we need the patch to be included in a koji build and submitted to bodhi asap 16:49:07 according to adamw's comment yes :) 16:49:08 that seems to be what we're waiting for here 16:49:12 alright, thanks 16:49:36 #agreed 641474 - waiting for patch to be included in koji build and bodhi update ASAP 16:49:42 who has the ball on that ... pjones or agk? 16:49:48 looks like there may be a build in koji already from agk 16:50:01 http://koji.fedoraproject.org/koji/buildinfo?buildID=200666 16:50:06 but it hasn't been submitted to bodhi 16:50:11 * Fri Oct 15 2010 Alasdair Kergon - 2.02.73-3 - Add --setuuid to dmsetup rename. - Add dm_task_set_newuuid to set uuid of mapped device post-creation. 16:50:21 okay 16:50:39 alrighty, anything else to add here? 16:51:19 #topic https://bugzilla.redhat.com/show_bug.cgi?id=641476 - devicemapper UUID field cannot be assigned after map creation 16:51:20 Bug 641476: medium, high, ---, agk, ON_QA, devicemapper UUID field cannot be assigned after map creation 16:51:39 #info pilot error -- please see previous discussion on bug matching same description 16:51:40 (i have to drop off at 1PM, fwiw) 16:52:07 notting: okay 16:52:25 #topic https://bugzilla.redhat.com/show_bug.cgi?id=643220 - Blocker bug for final version of release notes 16:52:27 Bug 643220: medium, low, ---, stickster, NEW, Blocker bug for final version of release notes 16:52:47 notting: I'm not sure if this is a _Tracking_ bug, but it may account for that additional update you mentioned 16:52:59 #link https://admin.fedoraproject.org/updates/fedora-release-notes-14.0.3-1.fc14 16:53:01 it's not a tracking bug 16:53:07 okay 16:53:12 it's just what it says: we need the final release notes build in for the rcs 16:53:28 is the bodhi update linked earlier intended as the *final* build? 16:53:35 do we need to link these together 16:53:52 yeah, i was wondering that - not sure 16:54:10 jjmcd is online but away 16:54:10 * jlaska posted to bz 16:54:30 okay, so it's probably it, but we still need to connect the dots 16:54:46 so ... blockery-ness? 16:55:06 This sounds like a common step during the release process, and not so much an unexpected issue? 16:55:58 yes, but it is a blocker, because we have to have the correct release notes in the release :) 16:56:03 * jlaska sees a "Coordinate release notes" task on the rel-eng SOP (http://fedoraproject.org/wiki/Release_Engineering_Release_Tickets) 16:56:20 adamw: right, I wasn't suggesting downgrading it ... just running it through the blocker wood chipper 16:56:31 yeah, we don't really have it in the process unfortunately 16:56:54 we could probably throw a criterion in there 16:57:04 toss it on the retrospective wishlist 16:57:18 proposed #agreed 643220 - accepted to F14Blocker. Bodhi update available, need to confirm this is the expected release-notes update 16:57:18 #action adamw to propose final release criterion for release note inclusion 16:57:23 ack/nak/patch 16:57:34 ack 16:57:48 anyone else ... 16:59:00 just emailed a proposed criterion to the list 16:59:12 #agreed 643220 - accepted to F14Blocker. Bodhi update available, need to confirm with jjmcd whether bodhi update is the expected release-notes update 16:59:15 adamw: thx 16:59:43 #topic https://bugzilla.redhat.com/show_bug.cgi?id=643580 - Fedora 14 TC1 DVD Graphical Install Fails 16:59:44 Bug 643580: medium, low, ---, xgl-maint, NEW, Fedora 14 TC1 DVD Graphical Install Fails 17:00:19 adamw: has some thoughts already posted to this issue 17:00:32 "ajax votes for this bug to be nice-to-have - take the 609245 fix in the hopes 17:00:35 that it solves this issue, if it doesn't, document the use of vesa as a 17:00:38 workaround. 17:00:41 " 17:00:45 i'd certainly vote for either blocker or nth status for this 17:00:58 note that the proposed fix is in RHEL 6 already so RH has pretty high confidence in it 17:01:29 it's a fix for graphics in xen pv guests? 17:01:30 the other 'new' proposed blocker turned out to be a dupe of this, btw, so we have at least four reporters who've hit it 17:01:35 no, nothing to do with virt. 17:01:42 fix should be built in anaconda-14.20 17:01:44 (in our experience anyway) 17:02:08 adamw: oh I see 17:02:09 The fix for #609245 tells the server never to regenerate. 17:02:10 which is the current build 17:02:32 so that's not specific to virt, but the original issue was against xen pv guests ... I see 17:02:51 clumens: which bz are you talking about? 17:03:04 609245 17:03:21 the reporter who's posted anaconda logs shows 14.19 in there, not 14.20 17:03:24 clumens: oh sorry, yes, that's against anaconda 17:03:27 what does TC1 actually have in it? 14.19 or 14.20? 17:03:40 14.19 17:03:50 ok 17:03:59 are we already planning to take 14.20 for rc1? 17:04:04 yeah 17:04:15 many of the ON_QA fixes are in 14.20 17:04:22 ok 17:04:26 so we should get this fix 'for free' 17:04:40 so how do you want to track this ... 17:04:50 move to NTH, and post for retest on 14.20-1 ? 17:05:01 as a process issue, though, why is this fix in 14.20? is it the fix for some other bug that was marked as blocker or nth? 17:05:02 or move it to MODIFIED pending retest on 14.20-1 ? 17:05:15 or is anaconda team just pulling RHEL 6 fixes into the F14 anaconda builds? 17:05:29 NTH isn't a bug status, so those two are not mutually exclusive 17:05:53 adamw: feel free to recommend an action 17:05:55 so, both 17:06:04 accept it as NTH, mark it as ON_QA 17:06:07 okay ... 17:06:10 er, wait, MODIFIED 17:06:15 well, whichever 17:06:52 proposed #agreed 643580 - accepted as 'nice-to-have' and move to MODIFIED. Team expects this to be resolved by a related fix in anaconda-14.20-1. Retest against F-14-RC1. 17:07:36 clumens: bcl: I think we'll need anaconda-14.21-1 today to take in #583906? 17:07:41 yes 17:07:43 #agreed 643580 - accepted as 'nice-to-have' and move to MODIFIED. Team expects this to be resolved by a related fix in anaconda-14.20-1. Retest against F-14-RC1. 17:07:54 clumens: thanks, just clarifying 17:08:49 okay, last NEW || ASSIGNED || MODIFIED F14Blocker issue ... 17:09:14 #topic https://bugzilla.redhat.com/show_bug.cgi?id=643951 17:09:16 Bug 643951: high, high, ---, schwab, NEW, CVE-2010-3847 glibc: ld.so insecure handling of $ORIGIN in LD_AUDIT for setuid/setgid programs [fedora-all] 17:09:37 I've added this to the f14 QA retrospective wishlist already 17:09:54 summary, I think high risk security issues can be included in the criteria 17:10:17 Oxf13 can confirm, but I believe we've historically included issues of this type 17:11:03 any objections/concerns/ideas? 17:11:08 no, i'm fine with it 17:11:13 okay 17:11:13 blocker or nth? 17:11:26 I gather that would depend on the severity 17:11:37 I think we'd probably want to follow-up eventually with the security team 17:12:56 I vote for requesting more info in the bz 17:13:21 well, the more info is likely in the CVE 17:13:23 b/c I have no idea if a fix is expected today, 2 weeks etc... 17:13:55 and https://bugzilla.redhat.com/show_bug.cgi?id=643306 17:13:55 Bug 643306: high, high, ---, security-response-team, NEW, CVE-2010-3847 glibc: ld.so insecure handling of $ORIGIN in LD_AUDIT for setuid/setgid programs 17:14:33 that bug has the discussion and proposed patch 17:14:36 it's a privesc bug, apparently 17:14:39 yeah, just catching up on that now 17:14:40 * adamw stifles a yawn 17:15:19 I'm not the security expert here 17:15:28 I can follow-up w/ schwab afterwards for an ETA 17:15:49 I agree on NTH or Blocker ... but can't explain one over the other 17:16:07 yeah, we should ask security team i guess 17:16:11 so ... for now, without an ETA, howabout NTH 17:16:22 and we'll reach out in the bug for feedback and escalate if needed 17:16:31 my inexpert reading is that privesc issues are a dime a dozen and basically you should just assume any user account has root privileges =) 17:16:50 i don't think we have any setxid programs using $ORIGIN... 17:17:10 jlaska: sounds reasonable 17:17:11 proposed #agreed 643951 - Unclear impact and ETA on fix, accepted as 'nice-to-have' pending additional feedback from maintainer 17:17:47 ajax: good to know 17:18:11 #agreed 643951 - Unclear impact and ETA on fix, accepted as 'nice-to-have' pending additional feedback from maintainer 17:18:34 adamw: want me to post the request for feedback in that bz? 17:19:00 already did it 17:19:04 * jlaska reloads 17:19:33 $ORIGIN's a pretty obscure linker feature. i could conjure up a scan for it if we really wanted, but i'd be very surprised if it found anything 17:19:35 perfect, thanks 17:20:11 ajax: if the heat goes up on this one, that could be useful. BUt I suspect we're fine for now 17:20:16 okay, that's it for my list 17:20:30 jlaska: pjones has been bugged. 17:20:33 open discussion time ... or adamw, do you want to walk NTH? 17:20:42 clumens: thanks for the follow-up 17:21:03 just let me see if there's any NTH requiring review 17:21:39 okay 17:21:41 #chair adamw 17:21:41 Current chairs: adamw jlaska 17:22:40 nope, no proposed NTH we haven't reviewed yet 17:22:59 cool, thanks for checking 17:23:06 #topic Open discussion - 17:23:24 anything not previously discussed that we need to review? 17:24:28 [A tumbleweed drifts past] 17:25:09 heh 17:25:16 gholms|work: it's the wild west of bugs here :) 17:25:27 ;) 17:25:30 alright, well let's close this puppy out so we can get back to testing 17:25:36 ... 30 seconds until #endmeeting 17:26:09 as always, thanks for your participation! 17:26:12 I'll send minutes to the list 17:26:14 #endmeeting