16:01:15 <poelcat> #startmeeting Fedora 14 Final Blocker Review http://bit.ly/aBqOcu
16:01:15 <zodbot> Meeting started Fri Oct 22 16:01:15 2010 UTC.  The chair is poelcat. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:36 <poelcat> who is present and accounted for?
16:01:42 * jlaska 
16:01:54 * red_alert 
16:02:17 <jlaska> I think brunowolff will be lurking as well
16:02:33 * spot is lurking
16:02:37 * brunowolff is here
16:03:09 * bcl waves
16:03:18 <poelcat> chair jlaska red_alert spot brunowolff adamw
16:03:24 <poelcat> #chair jlaska red_alert spot brunowolff adamw
16:03:24 <zodbot> Current chairs: adamw brunowolff jlaska poelcat red_alert spot
16:03:58 <poelcat> shall we jump in or wait for someone?
16:04:11 <jlaska> let's git'r'done
16:04:18 <jlaska> hopefully adamw can join shortly
16:04:30 <jlaska> and Oxf13
16:04:48 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=645283
16:04:49 <buggbot> Bug 645283: medium, low, ---, dhuff, NEW, livecd-tools should create a /etc/mdadm.conf so that Intel BIOS RAID arrays get auto started
16:06:10 <jlaska> reading Hans feedback in this bug, I believe the general consensus is to note this on Common_F14_bugs
16:06:25 * spot nods
16:06:29 <jlaska> my understanding of this issue ...
16:06:51 <jlaska> booting a live image on a system with intel bios raid, may not properly assembe existing arrays *until* you run anaconda/liveinst
16:07:04 <hicham> jlaska : is it still time to add a blocker ?
16:07:09 <jlaska> so bad things could happen if you muck with individual disks before assembling the array
16:07:15 <hicham> (sorry for interrupting)
16:07:21 <jlaska> hicham: will you be around to raise an issue during open discussion?
16:07:47 <jlaska> we don't have any release criteria that require the BIOS RAID be assembled properly on boot into a live image
16:07:58 <jlaska> and anaconda/liveinst does properly assemble the array when you are installing from the live image
16:08:09 <jlaska> so I think this is safe to document, and focus on resolving for F15/rawhide
16:08:11 <brunowolff> Do the file systems on those disks get seen where they might get automounted or something?
16:08:37 <spot> brunowolff: i'm not sure how they would.
16:08:44 <brunowolff> If you have to go out of your way to mess with them, it doesn't feel like a blocker.
16:08:48 <jlaska> brunowolff: I don't know ... but it may depend on how the BIOS Array was structured
16:09:13 <jlaska> nice that hans discovered and escalated this issue
16:09:33 <jlaska> so for me ...
16:09:50 <poelcat> is there anyone here who believes this bug should be an AcceptedBlocker?
16:10:05 <spot> not me
16:10:07 * jlaska votes -1 for Blocker and -1 for nice-to-have
16:10:25 <jlaska> +1 Common_F14_bugs
16:10:42 <red_alert> -1 Blocker, -1 NTH, +1 CommonBugs
16:11:18 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=645283, not an AcceptedBlocker or NTH, add to CommonBugs page
16:11:19 <buggbot> Bug 645283: medium, low, ---, bcl, NEW, livecd-tools should create a /etc/mdadm.conf so that Intel BIOS RAID arrays get auto started
16:11:22 <poelcat> ack/nak/patch?
16:11:28 <jlaska> ack
16:11:31 <spot> ack
16:11:33 <brunowolff> ack
16:11:47 <jlaska> I'll update the bz with the outcome
16:12:03 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=645283 livecd-tools should create a /etc/mdadm.conf so that Intel BIOS RAID arrays get auto started, not an AcceptedBlocker or NTH, add to CommonBugs page
16:12:03 <buggbot> Bug 645283: medium, low, ---, bcl, NEW, livecd-tools should create a /etc/mdadm.conf so that Intel BIOS RAID arrays get auto started
16:12:20 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=645293
16:12:22 <buggbot> Bug 645293: medium, low, ---, kernel-maint, NEW, kernel does not recognize the partitions on an mdraid array (Intel BIOS RAID)
16:14:05 <jlaska> another bios raid issue ...
16:14:27 <spot> -1 Blocker, -1 NTH, +1 CommonBugs
16:14:32 <jlaska> while hans was testing a fix for the previous bug, he then ran into this
16:14:34 <red_alert> -1 Blocker, -1 NTH, +1 CommonBugs
16:14:45 <jlaska> so while we should consider this on it's own merit, it is somewhat dependent on the previous bug
16:15:02 <jlaska> Hans seems to agree with +1 CommonBugs in the last comment as well
16:15:04 <spot> you can write them up together in CommonBugs. ;)
16:15:20 <jlaska> right on :)
16:15:33 <jlaska> I'm in agreement here ... -1 Blocker, -1 NTH, +1 CommonBugs
16:15:54 <jlaska> and the workaround here is to run 'liveinst' on the live image, which will correctly assemble the array and present existing partitions on the array
16:17:24 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=645283  kernel does not recognize the partitions on an mdraid array (Intel BIOS RAID), not an AcceptedBlocker or NTH, add to CommonBugs page, related to https://bugzilla.redhat.com/show_bug.cgi?id=645283
16:17:26 <buggbot> Bug 645283: medium, low, ---, bcl, NEW, livecd-tools should create a /etc/mdadm.conf so that Intel BIOS RAID arrays get auto started
16:17:27 <buggbot> Bug 645283: medium, low, ---, bcl, NEW, livecd-tools should create a /etc/mdadm.conf so that Intel BIOS RAID arrays get auto started
16:17:33 <poelcat> anything else on this bug?
16:17:36 * jlaska updates bug
16:17:40 <jlaska> I don't think so
16:17:52 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=645606
16:17:53 <buggbot> Bug 645606: urgent, low, ---, mclasen, NEW, Plain background used instead of Laughlin
16:18:42 <jlaska> I believe this is captured by our recently added artwork criteria
16:18:44 <jlaska> "The proposed final Fedora artwork is included and enabled by default for the installer, graphical boot, firstboot, graphical login and desktop background. All Fedora artwork must be consistent with the proposed final theme, and if any artwork contains a graphical version number, the version number used must match the Fedora release number. Generic release artwork (e.g. Alpha, Beta, Development) must not be used for the final releas
16:19:12 <jlaska> although, I do need to update the criteria to include the live image ... but when I drafted that, it was assumed
16:19:12 <spot> it looks like this is fixed in the kickstart, so if we spin another candidate it will be resolved?
16:19:35 <brunowolff> There is also a related issue that the desktop spin was oversize, which is why things were changing here after the freeze.
16:19:42 <jlaska> spot: I believe so.  I think we also want to determine whether it's a blocker on it's own merit as well
16:19:57 <jlaska> blocker vs nice-to-have I guess
16:20:17 * spot thinks it is a blocker if the Fedora background isn't showing up on the live image
16:20:20 <jlaska> brunowolff: right, so this comes from removing the animated backgrounds to reduce live image size?
16:20:20 <brunowolff> I haven't seen a nightly build since the 20th, so I don't have that confirmed as being fixed.
16:20:27 <jlaska> spot: agreed
16:20:33 <brunowolff> Essentially yes.
16:20:41 <jlaska> brunowolff: the RC1 images are mostly < 700 MiB
16:20:44 <jlaska> the design spin is larger iirc
16:20:55 <poelcat> so it sounds like this is a straight forward AcceptedBlocker bug because it doesn't meet the stated criteria?
16:20:58 <brunowolff> Design is targetting 1GB.
16:21:09 <jlaska> brunowolff: oh right, thanks
16:21:09 <spot> poelcat: that's my interpretation, yes. :)
16:21:14 <jlaska> poelcat: yeah
16:21:43 <brunowolff> For the set of nightly composes on the 20th, only live desktop was oversize (by about 4 MB).
16:21:46 <Oxf13> sorry I'm late, I'm here.
16:21:53 <adamw> sorry, i'm here
16:21:54 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=645606 AcceptedBlocker, new RC needed with a confirmed fix
16:21:55 <buggbot> Bug 645606: urgent, low, ---, mclasen, NEW, Plain background used instead of Laughlin
16:21:56 <adamw> was busy reading stupid blogs
16:21:58 <poelcat> ack/nak/patch?
16:22:10 <adamw> ack
16:22:14 <Oxf13> um, nack?
16:22:14 <jlaska> ack
16:22:17 <Oxf13> I can't reproduce this
16:22:17 <brunowolff> ack
16:22:30 <spot> Oxf13: there's a typo in the kickstart file?
16:22:36 <jlaska> Oxf13: I couldn't either at first, now I'm hitting every time
16:22:48 <Oxf13> hrm, goes back to read the bug
16:23:12 <brunowolff> It was a pasto. I copied text from broffice.org and didn't realize the long line had been broken as it looked ok visually.
16:23:23 <Oxf13> ok, weird results.
16:23:27 <Oxf13> I guess ack.
16:23:32 * jlaska notes ... I have no problem respinning just the live images for this ... I don't know if that is in concert with rel-eng policy though
16:23:34 <Oxf13> is this the only thing we've hit so far that requires a new RC?
16:23:44 <spot> Oxf13: sofar. :)
16:23:46 <Oxf13> ok
16:23:51 <jlaska> Oxf13: so far, but I believe we have other issue on the list
16:23:52 <Oxf13> then yes, we would just respin the Desktop live
16:24:01 <jlaska> Oxf13: okay
16:24:02 <Oxf13> and issue a 0-day update for spin-kickstarts
16:24:06 <jlaska> delicious!
16:24:14 <brunowolff> Jesse, have you done a desktop spin since the 20th? Is it under 703 MiB now?
16:25:21 <Oxf13> the RCs are under size
16:25:50 * poelcat not clear what proposed action is?
16:26:01 * jlaska attempts ...
16:26:27 <Oxf13> proposal: accepted blocker, commit fix to spin-kickstarts git repo, re-compose Desktop live images, issue 0-day update for spin-kickstarts
16:26:29 <adamw> fix the kickstart file, re-spin the desktop live image, and ship an update for spin-kickstarts package with the fix in it
16:26:43 <jlaska> yup, already said better by Oxf13  and adamw
16:26:52 <spot> sounds good to me (+1)
16:26:59 <jlaska> ack
16:27:13 <brunowolff> The fix is already commit to the F-14 branch of git repo.
16:27:17 <jlaska> if for some reason, we need to respin to RC2, we would include this?
16:27:25 <jlaska> (with all other media I mean)
16:27:41 <Oxf13> jlaska: it's a blocker, so yes
16:27:43 <brunowolff> The updated spin-kickstarts package?
16:28:36 <jlaska> Oxf13: okay, thanks
16:29:03 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=645606 AcceptedBlocker, commit fix to spin-kickstarts git repo, re-compose Desktop live images, issue 0-day update for spin-kickstarts
16:29:04 <buggbot> Bug 645606: urgent, low, ---, mclasen, NEW, Plain background used instead of Laughlin
16:29:15 <poelcat> #undo
16:29:15 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x2b5232e66790>
16:29:32 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=645606 Plain background used instead of Laughlin AcceptedBlocker, commit fix to spin-kickstarts git repo, re-compose Desktop live images, issue 0-day update for spin-kickstarts
16:29:33 <buggbot> Bug 645606: urgent, low, ---, mclasen, NEW, Plain background used instead of Laughlin
16:29:45 <poelcat> #topic Open Discussion (or more bugs)
16:30:04 <notting> who has the previous action?
16:30:08 <jlaska> I have one I'd like to add, but I suggest hicham goes first
16:30:15 <Oxf13> notting: I do.
16:30:18 <brunowolff> If spin-kickstarts isn't rebuilt before tonight I'll do it. Otherwise Jesse has had more practice doing it then he probably wanted.
16:30:28 <Oxf13> notting: the fix is already committed, I just have to re-make desktop live images
16:30:45 <Oxf13> and we can build the package at any time up to the release of F14
16:30:54 * hicham is looking for the bug number
16:30:59 <brunowolff> Unless there is an RC2?
16:31:18 <poelcat> #chair hicham
16:31:18 <zodbot> Current chairs: adamw brunowolff hicham jlaska poelcat red_alert spot
16:31:19 <brunowolff> Then wouldn't we it it built by then?
16:31:24 <Oxf13> brunowolff: right, if there is an RC2 I'll build the package for it.
16:31:48 <brunowolff> OK, I hold off then to make sure the fix is working.
16:32:08 <jlaska> hicham: while you're looking, I can propose one for discussion
16:32:44 <poelcat> can you guys drive from here?
16:32:46 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=645592
16:32:48 <buggbot> Bug 645592: medium, low, ---, jkeating, NEW, plymouth-themes-charge is on CD2, no graphical plymouth with split media installs
16:32:49 <adamw> sure
16:32:53 <hicham> jlaska: bug 639687
16:32:54 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=639687 urgent, urgent, ---, kernel-maint, NEW, Hard Lockup with r300g
16:33:00 * poelcat needs to step away
16:33:04 <jlaska> hicham: ah okay, let's go with yours first then
16:33:05 <poelcat> adamw: thanks
16:33:16 <jlaska> #info coming back to this topic shortly ...
16:33:20 <jlaska> #topic https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=639687
16:33:22 <buggbot> Bug 639687: urgent, urgent, ---, kernel-maint, NEW, Hard Lockup with r300g
16:33:33 <jlaska> hicham: okay, what do you have?
16:33:38 <adamw> "Computer locks up when playing intensive 3D games, or even flash content with
16:33:38 <adamw> lightspark." = not interested
16:33:41 <adamw> sorry :P
16:33:58 <hicham> adamw: these are just examples
16:34:09 <jlaska> iirc, we intentionally excluded 3D from the release criteria after discussion with the xorg-x11-drv-* folks
16:34:38 <adamw> yeah, but if you can get to a working basic desktop and it survives use to browse and install updates, it's very unlikely to be made a blocker
16:34:48 <adamw> since we can fix it with an update in that case
16:34:57 <Oxf13> nack
16:35:00 <Oxf13> er nack on blocker
16:35:05 <Oxf13> easily fixed in an update
16:35:17 <spot> nack's as a blocker also
16:35:38 <hicham> adamw: it seems to lock when using any OpenGL app
16:35:59 <adamw> like jlaska says, opengl is explicitly not a blocker at this point
16:36:15 <adamw> we can certainly commonbugs this and ask kernel team to backport the fix/workaround
16:36:28 <hicham> adamw: airlied is aware of it, and there are pending fixes
16:36:38 <hicham> i thought of adding to Common_Bugs, but I preferred to have your say on this
16:36:44 <jlaska> oh that's good, sounds like you probably won't have to wait long then
16:37:20 <hicham> ok, i will add it to common_bugs until it is fixed
16:37:33 <jlaska> I'm nack for this as well ... since 3d isn't enabled by default, we don't have high confidence in 3d support across the board yet, and it can be resolved in a post-release update
16:37:35 <Oxf13> should we respin, we could vote on this as nice to have
16:37:46 <adamw> right, that's what i was gonna say
16:37:47 <Oxf13> but then again, it's kernel, so...
16:37:57 <jlaska> yes, definitely would want to see the patch and have confidence that it's a low risk change
16:38:05 <adamw> looking at airlie'd proposed fix, if that works, i think we could take it
16:38:06 <jlaska> but we can re-review if needed
16:38:10 <adamw> jlaska: https://bugs.freedesktop.org/attachment.cgi?id=39604
16:38:20 <adamw> it looks like it skips a code path unless it's really needed, which ought to be quite safe
16:38:34 <Oxf13> fwiw I think we should just either say we'd take it or not, and let the kernel folks decide if it's low risk enough
16:38:40 <adamw> point
16:38:47 <Oxf13> since I'm not comfortable making that decision for them
16:38:51 <adamw> but yeah, let's revisit it if we go to rc2
16:38:56 <jlaska> Oxf13: good point, agreed
16:39:08 <Oxf13> adamw: are you keeping a list of these things somewhere outside of bugzilla?
16:39:22 <adamw> Oxf13: we can just propose it as NTH but not review it
16:39:26 <Oxf13> (because once we start pushing to 0-day updates repo, bodhi is going to be closing bugs and they'll drop from our trackers)
16:39:31 <adamw> Oxf13: so set it to block f14-accepted but don't add a whiteboard field
16:39:33 <adamw> ah, i see
16:39:35 <jlaska> proposed #action 639687 - not accepted as F14Blocker, may consider as a nice-to-have if kernel team considers the fix low risk.  Add CommonBugs keyword to document issue
16:39:46 <Oxf13> ack
16:39:47 <jsmith> ACK
16:39:53 <red_alert> ack
16:39:59 <brunowolff> ack
16:40:40 <jlaska> hicham: thanks for raising this issue for discussion
16:40:43 <adamw> no, i hadn't considered a way to track those yet
16:40:43 <adamw> ack
16:40:43 <adamw> Oxf13: i'll try and take a copy of the nth list before you start doing 0-day pushes
16:40:53 <adamw> hicham: can you test airlied's proposed patch asap? that's important to get it in if we do do further rcs
16:40:56 <jlaska> who wants to follow-up with airlied to get their input with regards to patch risk?
16:41:08 <adamw> i think for now we'd best check the patch actually works
16:41:19 <adamw> because if that's not really the fix there's not much point evaluating it :)
16:41:20 <hicham> adamw: i will
16:41:22 <jlaska> sure
16:41:41 <jlaska> #action hicham - test patch for 639687 to determine whether it resolves the reported issue
16:41:44 <jlaska> #action 639687 - not accepted as F14Blocker, may consider as a nice-to-have if kernel team considers the fix low risk.  Add CommonBugs keyword to document issue
16:41:47 <jlaska> #undo
16:41:47 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x2b523255e390>
16:41:48 <adamw> hicham: i guess you're ok with building kernels?
16:41:49 <jlaska> #agreed 639687 - not accepted as F14Blocker, may consider as a nice-to-have if kernel team considers the fix low risk.  Add CommonBugs keyword to document issue
16:41:54 <Oxf13> if airlied isn't around, kylem would be a good target too
16:42:22 <jlaska> alright ... next open-discussion bug ...
16:42:24 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=645592
16:42:25 <buggbot> Bug 645592: medium, low, ---, jkeating, NEW, plymouth-themes-charge is on CD2, no graphical plymouth with split media installs
16:42:38 <jlaska> this is linked in the test matrix, and I believe Oxf13 found this while testing split-media
16:42:44 <spot> common_bugs, not a blocker. I could go either way on NTH
16:42:54 <jlaska> I think the $subject spells it out clearly
16:42:54 <adamw> for me this is probably nth
16:43:18 <jlaska> I'm on the fence for this one, as we do have criteria to capture the graphical boot behavior
16:43:24 <jlaska> (but it's just not specific to split-media)
16:43:30 <adamw> where's that criterion?
16:43:40 * adamw looking but can't find it
16:43:48 * spot notes that there is an additional trivial workaround besides waiting for a new kernel update
16:43:54 <spot> just rebuild the initrd. :)
16:43:57 <adamw> 'rebuild your initrd'
16:43:57 <adamw> yeah
16:44:01 <adamw> well, initramfs, these days =)
16:44:01 <jlaska> "In most cases, the installed system must boot to a functional graphical environment without user intervention"
16:44:13 <jlaska> adamw: F-14-Alpha criteria
16:44:14 <adamw> nah, that doesn't cover it
16:44:17 <spot> jlaska: and it does, just in plymouth text mode. :)
16:44:25 <adamw> even if the boot process is text mode, you still get a graphical desktop at the end of it
16:44:36 <jlaska> adamw: how so?
16:44:39 <adamw> we call out graphical boot functionality in the X.org test day tests, IIRC, but not in the criteria
16:44:42 <jlaska> spot: heh ;)
16:45:02 <jlaska> adamw: am I mis-interpretting the Alpha criteria  above?
16:45:06 <adamw> jlaska: 'boot to a functional graphical environment' is meant to be about having a graphical environment at the *end* of boot, not during it
16:45:08 <adamw> yeah, i think you are
16:45:19 * spot agrees with adamw
16:45:22 <jlaska> ah! I see
16:45:29 <adamw> to put that criterion in non-poncey language, it means 'when you boot up, you should get into GNOME'
16:45:31 <jlaska> so this only means we're getting the text boot-theme
16:45:39 <adamw> yeah, this bug is only about the boot process
16:45:40 <jlaska> adamw: right on, I see now
16:45:54 <jsmith> I didn't get the text boot theme... was this only on split media?
16:45:58 <adamw> jsmith: yep
16:46:02 <jsmith> Ah...
16:46:20 <jlaska> okay, so fairly straight workaround on this ...
16:46:24 <jlaska> rebuild the initramfs
16:46:32 <adamw> so we have no criterion for this, it's a cosmetic issue only with an easy workaround which will go away at the first kernel update, and it only affects split media. i'm comfortable not calling it a blocker. =)
16:46:36 <jlaska> I'll add to CommonBugs for documentation
16:46:52 <jlaska> I considered it for 'nice-to-have' ...
16:47:06 <jlaska> but wasn't sure if mucking with the package list would in any way affect the live images too
16:47:16 <brunowolff> I reported a bug similar to this: https://bugzilla.redhat.com/show_bug.cgi?id=626919
16:47:17 <jlaska> or this is a pungi change, and therefore install ISO specific
16:47:18 <buggbot> Bug 626919: medium, low, ---, rstrode, CLOSED CURRENTRELEASE, plymouth-scripts appears to need a requires on plymouth (and coreutils)
16:47:18 <adamw> i think nth would depend on how icky the fix is
16:47:42 <Oxf13> couple points of input here
16:47:43 <jlaska> Oxf13: would this be another package to add to the pungi hack to get things on disc1?
16:47:47 <jlaska> Oxf13: go for it
16:47:52 <Oxf13> You only get graphical plymouth on supported hardware, not every system
16:47:52 <brunowolff> Supposedly it was fixed, but maybe the fix wasn't correct and a change in the package order masked the problem.
16:48:10 <Oxf13> this "problem" goes away the very first time you update the kernel, which it sounds like there will be a 0-day update
16:48:18 <adamw> Oxf13: well, 'supported hardware' is almost every system
16:48:25 <adamw> given that radeon, nouveau and intel all support it
16:48:27 <Oxf13> adamw: not true, it has to be a KMS system
16:48:35 <hicham> namely radeon, intel, nouveau
16:48:37 <adamw> Oxf13: which is 99% of all current systems
16:48:43 <jlaska> (excluding virt)
16:48:44 <Oxf13> I wouldn't say 99%
16:48:50 <Oxf13> but i digress
16:48:58 <adamw> Oxf13: yeah, not a major point, i'm just nitpicking.
16:48:59 <Oxf13> to continue....
16:49:22 <Oxf13> The fix might be as simple as more pungi tweaking, but it could also involve altering Requires(post) settings in some packages
16:49:26 <brunowolff> My rv280 doesn't work with KMS on 2.6.34+ kernels, so some that you might think support KMS don't.
16:49:37 <Oxf13> or tweaking it could land us back in trouble with the contents of CD1 not being a complete transaction
16:50:02 <jlaska> that's my concern about having it as a NTH
16:50:05 <notting> Oxf13: this does not fit Heinous. CommonBugs!
16:50:06 <adamw> yeah, me too.
16:50:06 <Oxf13> and since we're killing split media in F15, I'm loath to care enough about it to even attempt to fix it for F14
16:50:07 <jlaska> potentially disruptive
16:50:36 * spot agrees. don't set as NTH, let it die with split media.
16:50:37 <jlaska> Oxf13: I wouldn't use that as the rational for not accepting it for NTH ... but I get the general idea ... it's not a clear-cut low risk fix
16:51:00 <Oxf13> jlaska: so this group could decide it's NTH, but I as the package maintainer could decide it's too risky :)
16:51:23 <jlaska> without seeing a patch, I agree that it could be somewhat risky to fix
16:51:29 <jlaska> risky/disruptive etc...
16:51:48 <Oxf13> regardless of how it's fixed, it means altering the content of CD1 again.  Not something I'm willing to play with at this point
16:52:18 <jlaska> proposed #agreed 645592 - not accepted to F14Blocker or nice-to-have since it is unclear how to properly resolve with minimal risk at this time.  Add to CommonBugs and document simple workaround
16:52:29 <jlaska> ack/nak/patch
16:52:46 <Oxf13> ack
16:52:47 <red_alert> ack
16:52:54 <adamw> ack
16:53:03 <spot> ack
16:53:05 <jlaska> #agreed 645592 - not accepted to F14Blocker or nice-to-have since it is unclear how to properly resolve with minimal risk at this time.  Add to CommonBugs and document simple workaround
16:53:07 <brunowolff> ack
16:53:09 <jlaska> any follow-up action on this?
16:53:28 <adamw> since we're killing split media for f15, i don't see one :)
16:53:35 <Oxf13> somebody needs to the commonbugs dance
16:54:07 <jlaska> let's add it ... and I or adamw can document this in the next few days
16:54:20 * jlaska udpates bz
16:54:35 <adamw> did it already.
16:54:42 <notting> adamw: but what happens when we need split dvd?
16:54:47 <adamw> notting: fire.
16:54:55 <jlaska> adamw: thanks
16:54:59 <jsmith> notting: Dual-layer DVD :-p
16:55:17 <Oxf13> notting: we kill some software
16:55:19 <jlaska> one other issue from me ...
16:55:21 <Oxf13> or blu-ray
16:55:38 <red_alert> or big usbkeys
16:55:42 <jlaska> #topic https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=645645
16:55:43 <buggbot> Bug 645645: medium, low, ---, anaconda-maint-list, NEW, Another grub picture is shown before the regular one
16:55:45 <Oxf13> getting our mirror system to all upgrade to something that handles files greater than 4G would be fun
16:55:52 * adamw really needs to buy a blu-ray drive one of these days
16:55:57 <jlaska> I'm not proposing this as a F14Blocker ...
16:56:15 <jlaska> but I do want to make sure bugs in the matrix are discussed outside of just QA
16:56:27 <jlaska> I *think* the subject bug is only a factor on slow systems
16:56:43 <jlaska> where you first see the isolinux/syslinux prompt, before it presents the nice friendly F-14 themed boot graphic
16:56:52 <Oxf13> I'm not even sure how you'd go about fixing this
16:57:02 <adamw> get rid of that splash.lss file, if that's the cause?
16:57:03 <Oxf13> the problem is that you see the text prompt just before the graphical one is loaded?
16:57:10 <notting> it's always been like that
16:57:19 <jlaska> Oxf13: yeah, and I think when robatino and kparal reported this ... they might be using slower systems
16:57:22 <Oxf13> yeah, that's just "syslinux can be slow to load the graphic"
16:57:22 <jlaska> so the delay is longer?
16:57:24 * spot thinks we should mark it as an easter egg.
16:57:27 <jlaska> haha :)
16:57:31 <jsmith> What about a more generic (blank) splash.lss?
16:57:33 <adamw> ohh, this one - yeah, i've seen that in vms
16:57:38 <jlaska> adamw: yeah
16:57:40 <adamw> never seen it on real hardware
16:57:45 <red_alert> I think I've seen this on rather fast systems, just saying :)
16:57:47 <notting> spot: so, you have splash.lss say 'your system is not tall enough to ride'?
16:57:48 <Oxf13> jsmith: that would suck for systems that cannot display the graphic
16:57:57 <adamw> have it say 'ubuntu sucks'
16:57:59 <spot> notting: three words: dancing. hot. dog.
16:58:03 <jlaska> red_alert: oh really?  so it still transitions to the proper graphic right?
16:58:09 <jlaska> spot: bingo! :)
16:58:16 <adamw> dancing hot dog saying ubuntu sucks!
16:58:27 <red_alert> jlaska: it's just a flicker, long enough to recognize the image but not what's happening :)
16:58:31 <adamw> that's it, this one's DEFINITELY a blocker
16:58:33 <jlaska> red_alert: okay
16:58:51 <jlaska> adamw: haha, can you draft up a matching criteria for this to get accepted?
16:59:26 <spot> "Bugs which are PURE AWESOME must be resolved."
16:59:37 <adamw> give that man a hot dog
17:00:00 <jlaska> proposed #agreed 645645 - not accepted as a F14Blocker or 'nice-to-have', appears to be a short delay on some environments when transitioning to the F-14 themed graphic.  Recommend hot-dog themed easter-egg for F15/rawhide :)
17:00:13 <adamw> ack
17:00:18 <Oxf13> pretty sure that's going to be closed as NOTABUG
17:00:19 <spot> ack
17:00:19 <adamw> it's a bit ugly, but i don't think we should poke it at this time
17:00:20 <Oxf13> or CANTFIX
17:00:44 <adamw> well, to 'fix' it, just make that graphic a black screen
17:01:13 <jsmith> Or a less distracting version, at least
17:01:17 <Oxf13> which again I think ruins the experience for people who can't see the graphic
17:01:29 <Oxf13> the useful non-graphic prompt is there for a reason
17:01:35 <red_alert> it's not really distracting IMHO
17:01:53 <jlaska> #agreed 645645 - not accepted as a F14Blocker or 'nice-to-have', appears to be a short delay on some environments when transitioning to the F-14 themed graphic.  Recommend hot-dog themed easter-egg for F15/rawhide :)
17:02:02 <jlaska> #topic Open discussion - <your bug here>
17:02:10 <jlaska> any other issues folks would like to discuss?
17:02:35 * jlaska brb ... someone grab the wheel
17:02:40 <Oxf13> I think the kernel folks have a thing to talk about
17:03:07 <Oxf13> trying to haul them in
17:04:18 <adamw> Oxf13: well, i meant a black screen with the prompt on it, whatever. just make the *graphic* nothing but black pixels.
17:04:28 <adamw> but whatever, not a big deal.
17:04:53 <adamw> i think i have actually got stuck at that screen once, can't remember what i broke to make it happen, though. i think if it can't find the root disk.
17:05:14 <Oxf13> you can hold down a key and get it I think
17:05:52 <kylem> i'd like to propose kernel-2.6.35.6-48.fc14 for f14... fixes a couple local root issues, and a suspend/resume bug on a lot of thinkpads due to TPM.
17:06:06 <red_alert> adamw: there's been a TC that got stuck on that screen :) I had you verify this at fudcon zurich :)
17:06:24 <adamw> oh goody, a borderline call :/
17:06:25 <adamw> red_alert: oh yeah!
17:07:12 <adamw> taking security fixes is obviously good
17:07:12 <Oxf13> kylem: trying to pull up bugs
17:07:21 <red_alert> kylem: does that actually fix CVE-2010-3904 too? I'd love to see this fixed in the release
17:07:27 <adamw> otoh, the practical impact of a privesc issue on a kernel that you'd only use to install is probably not huge
17:07:27 <Oxf13> I think immediately we'd take this as nice to have
17:07:35 <adamw> yeah, clearly nth
17:07:40 <Oxf13> the question on the table I think is take this as a blocker, respin everything, and possibly slip
17:07:42 <adamw> but at this point we have nothing else to prompt an rc2
17:07:54 <adamw> so this has to be a blocker to get in, as things stand
17:08:43 <red_alert> I was actually thinking about proposing this kernel security issue a blocker: https://bugzilla.redhat.com/show_bug.cgi?id=645305
17:08:44 <buggbot> Bug 645305: high, low, ---, kernel-maint, NEW, CVE-2010-3904 Linux RDS Protocol Local Privilege Escalation
17:08:46 <adamw> i think on instinct i'm weakly -1 blocker
17:09:12 <Oxf13> I vote for non-blocker as well, but that may be because I don't want to throw away all the work I did yesterday
17:09:22 <adamw> because if you think through the security impact, it really isn't much
17:09:39 * jlaska back
17:09:43 <adamw> why would you actually set up a multi-user production system using this kernel, even if we ship with it?
17:09:44 * jsmith is back too
17:10:10 * jsmith just noticed that the GDM background on F14 is still the F13 background
17:10:15 <kylem> if that's the metric, then why do we fix any bugs at all for release?
17:10:16 <pjones> adamw: doesn't matter why - people do it.
17:10:34 <adamw> kylem: mostly the bugs we take as blockers are bugs that we can't well fix with updates
17:10:45 <brunowolff> Because some bugs make it hard to get fixes after install.
17:10:50 <adamw> kylem: a lot of them are anaconda bugs; others are bugs which stop you being able to install or update in some way. that's mostly what the criteria focus on.
17:10:56 <pjones> and that's a fair point.  it's your previous one we're taking issue with ;)
17:11:27 <kylem> we spent months fixing bugs for release.
17:11:45 <kylem> anyway, that's fine.
17:11:56 <adamw> sidetrack.
17:12:05 <jlaska> kylem: is this a nice-to-have set of fixes ... or a critical severity ...
17:12:09 <jlaska> erm
17:12:12 <brunowolff> Is there a risk of machines getting broken into during the install process if those bugs are fixed?
17:12:22 <brunowolff> s/are/aren't/
17:12:32 <adamw> this is what i'm trying to get at
17:12:35 <adamw> i can't see one
17:12:47 <Oxf13> jsmith: we'll get to that issue in a moment.
17:13:02 <jlaska> was kylem representing the kernel team, or the security team when discussing those issues
17:13:04 <jsmith> Oxf13: OK..
17:13:36 <adamw> i mean, maybe if you're doing a remote desktop install?
17:13:36 <adamw> and someone somehow breaks into the session?
17:13:39 <jlaska> perhaps moot, but curious where the motivation was coming from.  Imo, it makes a difference if the security group is recommending we take something as a respin
17:13:41 <Oxf13> kernel team I believe
17:14:18 <jlaska> not to discount kernel-devel feedback, but when it comes to security sensative issues, I'd like feedback from the security experts
17:14:33 * jlaska notes ... I've got a TODO on the retrospective to propose security-related release criteria
17:14:41 <jlaska> anything else to discuss here?
17:14:47 <jlaska> ^---> on this kernel respin?
17:14:56 <Oxf13> did we ack it as NTH?
17:15:03 <Oxf13> I propose it as NTH
17:15:18 <brunowolff> +1 NTH
17:15:19 * adamw ack for NTH
17:15:39 <spot> ack
17:15:40 <jlaska> this assumes positive bodhi karma already, rightt?
17:15:42 <pjones> it's a local exploit, right?
17:16:34 <adamw> there's three CVEs in the changelog
17:16:58 <adamw> oh, four
17:17:27 <adamw> CVE-2010-3904 is the big one, and it says 'local', yeah
17:17:38 <adamw> i think jlaska's right it'd be good to ask a security expert
17:18:16 <jlaska> anyone interested in getting feedback from the security team on this (and red_alert's issue)?
17:18:26 <jlaska> or ... is there someone we can pull in on IRC?
17:18:36 <red_alert> +1 NTH only if we're sure no bad eprson gains acess to the system while installing - if we're not sure, +1 blocker
17:18:37 <adamw> i can see if vdanen's around, he's my pet security guy
17:18:56 <jlaska> ah, and he's a fellow canuck'head
17:19:00 <Oxf13> pjones: yes, I believe they are all local exploits, not remote
17:19:27 <Oxf13> jlaska: I think that can happen in the background, just have it done before our next blocker meeting
17:19:34 <Oxf13> this can always be re-proposed as a blocker.
17:19:56 <jlaska> Oxf13: yeah agreed.  I'll give them another minute or so, and then we can move on
17:20:17 <jlaska> adamw: any luck, or should we take this offline?
17:20:33 <adamw> sorry, dropped off for a minute
17:20:35 <adamw> just a sec
17:21:20 <jlaska> anyone else have issues to raise while we're waiting?
17:21:35 <adamw> vdanen says to wait 15 mins, so probably best do it by email
17:22:07 <jlaska> proposed #agreed - kernel-2.6.35.6-48.fc14 accepted as 'nice-to-have', looking for feedback from security team for thoughts on CVE severity
17:22:28 * red_alert was bitten badly by that one CVE today, but I figure installs are fairly safe
17:22:36 <jlaska> proposed #action adamw + vdanen - review severity of CVE's included in kernel-2.6.35.6-48.fc14 (and 645305)
17:23:13 <notting> do we have a timelimit on that action?
17:24:38 <adamw> i can probably get his input in a couple hours at worst
17:24:48 <jlaska> notting: are you looking for a point of no return where any respins will introduce a slip?
17:24:56 <jlaska> #agreed - kernel-2.6.35.6-48.fc14 accepted as 'nice-to-have', looking for feedback from security team for thoughts on CVE severity
17:25:00 <jlaska> #action adamw + vdanen - review severity of CVE's included in kernel-2.6.35.6-48.fc14 (and 645305)
17:25:03 <jlaska> adamw: thank you
17:25:16 <notting> jlaska: in the sense that if we're waiting on said feedback in order to do  <something>, we don't want to be waiting arbitrarily long
17:25:18 <adamw> when's go/no-go?
17:25:35 <jlaska> adamw: tues
17:25:39 <jlaska> @ 5pm EDT
17:26:06 <Oxf13> don't we have another blocker review on Monday
17:26:08 <brunowolff> Are the update live images going to replaces those in the RC1 directories?
17:26:10 <Oxf13> or is it on Tuesday?
17:26:12 <adamw> i'd say we probably need to have any rc2 built today (or tomorrow?) to avoid slipping...
17:26:16 <Oxf13> or do we just use the go-nogo as the blocker review?
17:26:19 <jlaska> note, robatino and rhe have developed a plan regarding which tests need to be reset in the matrix
17:26:46 <jlaska> Oxf13: we'll likely have some issues to review at go/no-go
17:26:51 <adamw> i think if we bump the kernel we have to play it safe and re-test everything
17:26:57 <jlaska> Oxf13: I don't see another scheduled review on the schedule (schedule)
17:27:09 <jlaska> (extra rschedule added because 3 is better)
17:28:11 <Oxf13> gotcha
17:28:25 <jlaska> adamw: the changes certainly impact what tests need to be repeated ... I expect they'll review and adjust as needed
17:28:26 <Oxf13> adamw: yes, and to get everything re-produced is going to take a day+
17:28:40 <jlaska> okay ... anything else to discuss ?
17:28:43 <Oxf13> so taking in a kernel at this point is almost 100% slip
17:29:17 <brunowolff> I would like to know where I can grab a live desktop iso respin if we don't do an rc2.
17:29:37 <brunowolff> I want to test the background issue to see if it is really fixed.
17:29:38 <jlaska> Oxf13: I'm less than 100%, only because it really depends on the community test response we get
17:30:00 <jlaska> obviously, if we have a great turn-out again, we'll be in better shape
17:30:03 <Oxf13> jlaska: we probably wouldn't have images to test until sometime my saturday
17:30:09 <Oxf13> (if I get time to work on it this weekend)
17:30:19 <Oxf13> maybe even Sunday
17:30:35 <jlaska> Oxf13: definitely 'plaid' at that point :)
17:30:37 * spot needs to go eat before he passes out from hunger
17:30:39 <jlaska> Extremely 'at risk'
17:30:43 <jlaska> okay ... let's wrap up here
17:30:50 <jlaska> so 2 big follow-up items
17:30:55 <jlaska> respin the desktop live images
17:30:59 <jlaska> feedback from security teawm
17:31:00 <jlaska> team
17:31:12 <jlaska> I'll send minutes to the list ... thanks all for attendance and input
17:31:22 <jlaska> #endmeeting