16:25:14 <adamw> #startmeeting 2009-11-06 blocker bug review meeting
16:25:14 <zodbot> Meeting started Fri Nov  6 16:25:14 2009 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:25:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:25:21 <adamw> #topic welcome
16:25:31 <adamw> welcome to the shortest bug review meeting ever, i am your host adamw, blah &c
16:25:36 <jlaska> I'm jlaska, and it's been 2 days since I filed a blocker bug
16:25:46 <adamw> *claps*
16:25:59 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=529292
16:26:01 <buggbot> Bug 529292: high, low, ---, bskeggs, MODIFIED, Graphics hang with KMS on nVidia 7800GT with FC12 beta RC2 install
16:26:23 <adamw> so, this is fixed, as three reporters confirm
16:26:26 <adamw> fourth hasn't tested yet
16:26:29 <adamw> let's close it!
16:26:35 <Oxf13> well, short, but long because we're about to add 2 or 3 blocker bugs
16:27:06 * jlaska takes egg for not properly announcing this event
16:27:40 <adamw> Oxf13: i don't believe that is permitted =)
16:28:26 <adamw> #agreed 529292 is closed, fix it.
16:28:28 <adamw> er
16:28:38 <adamw> #agreed 529292 is fixed, close it.
16:28:38 <adamw> :)
16:30:06 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=533236
16:30:08 <buggbot> Bug 533236: high, low, ---, xgl-maint, MODIFIED, X server failure with xorg-x11-server-Xorg-1.7.1-6 and Radeon X300
16:30:21 <jlaska> tested and fixed on my end
16:31:12 <adamw> would you be so kind as to post a comment to that effect in the bug?
16:31:23 <jlaska> oops, yes of course
16:32:42 <jlaska> shall I close it out as well, or would you like to get a few more positive results?
16:32:54 <Oxf13> just close it (:
16:33:02 <jlaska> Oxf13: sure is tempting!
16:33:05 <adamw> nah, go ahead, we'll re-open if anyone still hits it
16:33:53 <adamw> #agreed 533236 is fixed as confirmed by jlaska, he will close it
16:33:56 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=474225
16:33:57 <jlaska> okay closed
16:33:57 <buggbot> Bug 474225: urgent, low, ---, anaconda-maint-list, MODIFIED, Touchpad doesn't work in installer
16:34:23 <adamw> this is almost certainly fixed, we're only waiting on testing
16:34:34 <adamw> i've been trying to catch tirloni when he's online but no joy so far
16:36:05 <adamw> i guess we just leave it until he shows up
16:36:17 <jlaska> I think so
16:36:21 <adamw> we could drop it from the blocker list on the basis it's not a 'blocker' any more since we're pretty sure it's fixed? dunno if that's spurious
16:36:34 <jlaska> was it a blocker before?
16:36:47 <adamw> it's listed as one
16:36:51 <adamw> i dunno if it really is
16:36:58 <adamw> it got a free pass since it was in 'modified' quite early
16:37:03 <notting> jlaska: adamw: so, the two livecd install issues are work-around-able?
16:37:28 <adamw> notting: one is actually the glibc corruption bug that's been fixed
16:37:32 <jlaska> notting: I don't have details on the livecd install issues yet
16:37:33 <adamw> notting: he was using the pre-fix qemu
16:37:57 <jlaska> oh oh ... the previous blocker issues?
16:38:06 <adamw> yes
16:38:13 <adamw> warren's apparently may be too small a disk image
16:38:41 <adamw> are those the two you're thinking of notting?
16:40:44 <Oxf13> thats what I saw
16:40:54 <Oxf13> it's something of a bug if anaconda doesn't tell you in the liveinst case that your partitions are too small
16:41:01 <Oxf13> but I don't think it's a blocker bug
16:41:27 <adamw> yeah, it's unfortunate but live-with-able
16:41:40 <jlaska> do we have a bz yet, or still inprogress?
16:41:43 <adamw> and would probably be a bit of an invasive change to plumb in now anyway. plus it'd need translation
16:42:09 <adamw> i don't think this is anything new, anyway, i'm sure it was the same in previous releases and no-one died.
16:42:31 <jlaska> ah, I understand the issue now
16:42:43 <jlaska> yeah, I think it's perfectly acceptable to document
16:42:52 <jlaska> you're already trashing your disk
16:43:05 <adamw> i can throw it in common bugs on the reasoning that anaconda not warning you is a 'bug'
16:43:07 <jlaska> so if you hit this issue, reboot (or restart livinst) and follow the documented instructions for partition sizes?
16:43:32 <adamw> yeah, custom partition to make / big enough to fit, or if you're in a vm, make the disc bigger
16:43:48 <adamw> apparently the root image is 2.2GB, so basically you need / to be at least that big.
16:44:13 <adamw> hughsie confirms his issue was the broken qemu, yay.
16:44:39 <adamw> so, on 474225, should we just drop it on the basis it's not important enough to be a blocker anyway?
16:44:44 <adamw> workarounds: use the keyboard, plug in a mouse
16:44:53 <Oxf13> yeah, drop it
16:45:33 <jlaska> is this one laptop
16:45:36 <jlaska> or a range?
16:45:48 <jlaska> sorry ... just wanna make sure we aren't passing on somethign bigger
16:45:49 <adamw> i think it's several macbooks
16:46:40 <jlaska> hrmm ... I'd like to keep it on awaiting feedback.  Is there harm in that ... and closing it monday?
16:46:46 <adamw> nah, guess not
16:46:49 <jlaska> I think I'm outvoted anyway ... so that's okay
16:46:59 <adamw> i'm happy with that if you want to do it that way
16:47:10 <adamw> unless someone is going to punish oxf13 for the blocker list not being empty or something
16:47:11 <jlaska> but I'll close it out first thing monday morning
16:47:49 <adamw> ok, let's just do it that way
16:47:52 <Oxf13> well, it just seems silly to keep it on if we wouldn't actually slip if its still broken
16:48:01 <jlaska> yeah .. good point
16:48:02 <adamw> heh
16:48:10 <jlaska> so we decided to slip for this earlier
16:48:16 <jlaska> but now the bar is a little higher
16:48:17 <adamw> i'm not sure we really _did_
16:48:22 <adamw> as i said it always got kind of a free pass
16:48:26 <jlaska> okay
16:48:29 <adamw> as we were always fairly sure we knew what was going on with it
16:48:31 <jlaska> yeah, you're right
16:48:48 <jlaska> you sold me
16:49:01 <jlaska> request testing again and move to target?
16:49:08 <adamw> yay agreement
16:49:17 <jlaska> thanks for the hand hold ;)
16:49:28 <adamw> Oxf13: good for you?
16:49:32 <jlaska> and sorry for the sweaty palms
16:49:53 <Oxf13> fine by me
16:50:13 <adamw> alrighty
16:50:31 <adamw> #agreed 474225 isn't really a blocker, we gave it a free pass before. we're pretty sure it's fixed, but dropping from the list to target
16:51:19 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=533236
16:51:20 <buggbot> Bug 533236: high, low, ---, xgl-maint, CLOSED RAWHIDE, X server failure with xorg-x11-server-Xorg-1.7.1-6 and Radeon X300
16:51:27 <adamw> oh hey lookit that, it got closed!
16:51:32 <adamw> #agreed 533236 - false alarm
16:51:48 <adamw> er, i linked the wrong bug
16:51:48 <adamw> heh
16:52:03 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=533363
16:52:05 <buggbot> Bug 533363: medium, low, ---, xgl-maint, NEW, Latest rawhide x server crashing
16:52:06 <adamw> damn similar numbers
16:53:41 <adamw> so, this is almost certainly a dupe of 533363
16:53:45 <jlaska> yeah, I agree
16:53:48 <jlaska> same backtrace
16:53:54 <adamw> the reporter reported with 1.7.1-6 that it's broken and has just reported that 1.7.1-3 works, which matches
16:53:57 <adamw> the backtrace is the same
16:53:58 <jlaska> same single monitor nouveau reproducer you found
16:54:18 <adamw> and he hasn't tried 1.7.1-7 yet
16:54:27 <adamw> i've just added a comment explaining this and asking him to please try 1.7.1-7
16:55:12 <adamw> so, yeah, i'm not elevating the pantscon level on this one
16:55:23 <jlaska> haha
16:55:29 * jlaska agrees
16:56:55 <adamw> we invented pantscon levels...day before yesterday I think
16:56:57 <adamw> it works like defcon
16:57:51 <Oxf13> although defcon kind of works, def(ecation)con
16:58:04 <adamw> heheh, hadn't thought of that
16:58:16 <jlaska> okay, you guys have been up too late for too many nights in a row ;)
16:58:32 <adamw> #agreed 533363 is almost certainly 533236, adamw is confirming
16:59:12 <adamw> so that's everything we know about...
16:59:19 <adamw> except this luks unpleasantness warren is hitting in -devel
16:59:35 <jlaska> yeah ... there will be more bugs coming
16:59:44 <adamw> jlaska: have we done any encrypted install testing yet, to the point of actually booting the encrypted install?
16:59:50 <jlaska> so ... for completeness, you guys up for a quick review of what we have on th einstaller matrix?
16:59:53 <Oxf13> wait that's not everything we know about
16:59:56 <jlaska> adamw: sure have ... no issues found yet
16:59:59 <adamw> Oxf13: ooh sorry, missed a bit?
17:00:00 <Oxf13> I have some issues to bring up
17:00:03 * jlaska as well
17:00:06 <adamw> please do
17:00:09 <adamw> #topic open floor
17:00:10 <Oxf13> there is install to iscsi failure
17:00:20 <adamw> right - is there a bug report for that yet, for housekeeping?
17:00:35 <Oxf13> which is due to missing dracut-network package on the DVD
17:00:55 <Oxf13> I have more, just a sec, need to get kid some drinkm
17:01:10 <jlaska> one sec ...
17:01:20 <jlaska> I was planning to walk through the matrix bugs ...
17:01:23 <adamw> jlaska: i believe you consider the iscsi bug to be reasonably workaround-able, right?
17:01:38 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=533392
17:01:39 <buggbot> Bug 533392: medium, low, ---, notting, NEW, dracut-network not included in F-12-RC1 DVD install
17:02:00 <Oxf13> I bring it up because it's a very simple fix and we may need to respin anyway
17:02:05 <Oxf13> due to some other issuess I have to bring up
17:02:28 <Oxf13> We have two packages with broken deps, /both/ of which exist in some part on the DVD
17:02:40 <Oxf13> so the DVD has broken deps, that's not shippable.
17:03:05 <adamw> if we do need to respin then i'm +1 to fix this at the same time
17:03:23 <adamw> if one of the broken deps issues is lynx, sorry for bumping it off the blocker list :( i didn't realize exactly how it panned out
17:03:26 <Oxf13> We have to respin the DVD set with an updated lynx and gnome-python2-extras
17:03:44 <adamw> ok, so, one thing at a time
17:03:45 <Oxf13> adamw: I didn't know either because the fedora-release-notes which broke its dep wasn't tagged yet
17:03:52 <adamw> yowch.
17:04:15 <adamw> i think the position for 533392 is that we wouldn't really block the release for it, but we should take the fix if we're respinning anyway
17:04:19 <adamw> right?
17:04:30 <jlaska> yeah, nie to have for me
17:05:16 <adamw> Oxf13: wdyt?
17:05:24 <Oxf13> adamw: yes
17:05:27 * adamw notes his short-meeting dreams sailing out the window
17:05:28 <adamw> okie dokie
17:05:33 <Oxf13> tbf, iscsi is just one instance of what this breaks
17:05:40 <Oxf13> I think any form of network root would fail
17:05:47 <adamw> #agreed 533392 is not a blocker, but we will take the fix if we re-spin anyway (which is likely)
17:05:50 <jlaska> yup, this affects any netboot setup
17:05:55 <jlaska> nbb, iscsi, and nfs
17:06:09 <adamw> ah, k, that is worse
17:06:41 <adamw> ok, so, the lynx/indexhtml issue is basically https://bugzilla.redhat.com/show_bug.cgi?id=533004
17:06:43 <buggbot> Bug 533004: medium, high, ---, jmoskovc, NEW, fedora-release-notes obsoleted indexhtml without providing it
17:06:45 <Oxf13> so if pushed, I'd actually fall on teh side of it being a blocker
17:07:03 <adamw> actually with that level of impact i'm inclined to agree, even if it's workaround-able
17:07:25 <adamw> the workaround could be tricky if you're, say, doing an internal network install from an exploded dvd image with no internet connection available
17:07:34 <adamw> for some weird reason - sounds insane to me but i'm sure someone has a reason to do it
17:07:36 <jlaska> which, seems rare
17:08:20 <adamw> 'i took the fedora 12 dvd to install in my super-sekrit nuclear bunker and now i'm screwed! am sending this message by semaphore! CURSE FEDORA FOR ME!'
17:08:25 <Oxf13> good news is that these aren't really code changes, which shouldn't invalidate any existing testing
17:08:28 <adamw> right
17:08:33 <jlaska> yes
17:08:46 <adamw> well, in theory. heh. it _can_ happen, but rather unlikely.
17:09:32 <adamw> so, i'm +1 to make it a blocker actually, if oxf13 is +1 i guess we do
17:11:44 <Oxf13> ok, that's it for issues I'm aware of
17:12:06 <Oxf13> jlaska: you had a matrix to go over?
17:12:14 <jlaska> yeah ... let's take a look ...
17:12:18 <adamw> hold on hold on
17:12:22 <adamw> we didn't make everything nice and formal
17:12:23 * jlaska waits
17:12:25 <adamw> gimme a minute here
17:12:29 <jlaska> adamw: you're right, sorry
17:12:41 <adamw> #agreed 533392 overriding previous agreement, this is a blocker, will be fixed in the respin by including dracut-network
17:13:03 <adamw> is 533004 the bug for lynx's indexhtml dependency? or is there a separate bug for that?
17:13:25 <adamw> in either case, if it's a blocker we need to (re)-add the appropriate bug to the blocker list
17:16:08 <adamw> *crickets*
17:16:25 <Oxf13> adamw: there is the bug you dropped from the Blocker yesterday
17:16:27 <Oxf13> that would suffice
17:16:29 <adamw> alright, i propose we update 533004's summary to be more accurate and add it back to the blocker list
17:16:31 <Oxf13> and I think we have a build for lynx
17:16:35 <adamw> yeah, it's in the bug
17:17:47 <adamw> proposed comment: "as this introduced a broken dep on the DVD - which is not shippable per our release criteria - this should have been a blocker, apologies for dropping it. Updating the summary to reflect the current agreement over what the real issue is here, and re-adding to the blocker list. this will be fixed in an RC re-spin."
17:19:41 <Oxf13> worksforme
17:19:49 <adamw> welcome to the party warren :) sorry we didn't really advertise this meeting in advance
17:19:57 <jlaska> that's my fault ^^^ :(
17:20:23 <adamw> ok, so
17:20:46 <adamw> #agreed 533004 goes back on the blocker list with an updated summary as it resulted in a broken dep on the DVD, will be fixed with an updated lynx in the re-spin
17:21:18 <jlaska> this is a prime candidate for the soon to be born project ... "is anaconda broken?"
17:21:24 <adamw> heh
17:21:30 <jlaska> but, news on that @ 11
17:21:40 <adamw> so, what's the bug number for the gnome-python-whatthehellever dep?
17:22:02 <notting> adamw: there isn't one?
17:22:15 <adamw> if it's a blocker there really should be
17:22:22 <adamw> shall we file one quickly? what's the issue?
17:22:39 <notting> it has a broken dep on libgdl
17:22:49 <notting> we have a fixed package. but it's part of the xulrunner refresh
17:23:04 <Oxf13> notting: I'd prefer to get a package that's /not/ part of xulrunner
17:23:10 <jlaska> that's a security update, no?
17:23:25 <notting> Oxf13: easier said than done
17:23:43 <adamw> since it sounds like there's some discussion to be had here that's all the more reason to have a bug report
17:23:43 <Oxf13> notting: yes, but taking all of xulrunner deps is going to be world of eww
17:24:09 <adamw> can someone who's in the know on this issue file one? i don't want to screw up the description
17:25:50 <jlaska> notting: is that something you can help with?
17:26:10 <notting> sure, in a minute
17:27:20 <adamw> i am with oxf13 in wanting a fix that doesn't touch xulrunner if humanly possible
17:27:56 <adamw> just to be clear - if we take a 'fix' in an updated xulrunner we have to rebuild and take all the other dozen things that depend on xulrunner, right?
17:28:26 * jlaska shivers
17:28:54 * warren notes rpmdiff like <that thing we shouldn't talk about> would be very usefl here.
17:29:06 <jlaska> warren: talk about rpmqguard
17:29:17 <jlaska> http://kparal.wordpress.com/2009/10/21/rpmguard-print-important-differences-between-rpms/
17:30:10 <notting> adamw: it's all already built.
17:30:17 <notting> adamw: and there's a tag request.
17:30:49 <adamw> notting: as in, 'take onto the dvd'
17:30:57 <Oxf13> yes
17:31:05 <notting> but there's no rebuilds we'd have to wait for
17:31:06 <Oxf13> I'd have to shove another 8~ packages or so into my side repo
17:31:14 <Oxf13> and hope I get the multilib right
17:31:17 <adamw> it's not the waiting that is worrying :)
17:31:34 <Oxf13> and hope that nothing broke in the new firefox et al release
17:31:38 <adamw> it's the 'shoving multiple rebuilds onto the dvd can't possibly break anything'-ness of it
17:31:53 <Oxf13> I'd /really/ rather see those go to updates-testing for a bit
17:32:15 <notting> the alternative is untagging thigns from the build root, rebuilding, re-tagging things, and rebuilding *again*
17:32:32 <Oxf13> all it would really take is to remove xulrunner from the buildroot, bump/build gnome-python2-extras, tag it, and then put xul back in teh buildroot to build gnome-python2-extras again for the xul update
17:32:38 <Oxf13> not really that hard, I can start that right now.
17:32:53 <Oxf13> notting: it's /one/ thing in the buildroot to manage
17:33:00 <Oxf13> 2 builds total.
17:33:25 <adamw> notting: the advantages are two. a), the thing we're rebuilding is only one thing and less important than xulrunner. b), jesse doesn't have to do the stuff manually in a side repo. right, jesse?
17:33:40 <notting> meh. if everyone's going to get the new FF, i'd just ship it. but .. *shrug*
17:33:45 <notting> Oxf13: did you tag lynx?
17:33:49 <Oxf13> notting: not yet
17:33:53 <notting> shall i?
17:34:10 <Oxf13> sure
17:34:39 <notting> ok, tagging.
17:34:47 <adamw> #topic Unfiled (HINT HINT) release-blocking xulrunner dependency issue
17:35:12 <notting> eh?
17:35:16 <notting> the broken dep isn't on XR
17:35:19 <notting> and it's filed. P
17:35:22 <adamw> still waiting for a bug report :)
17:35:24 <adamw> ah, linky?
17:35:37 <notting> bug 533420
17:35:38 <adamw> (re xulrunner bit: see, that's why i didn't file it myself :>)
17:35:38 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=533420 medium, low, ---, mbarnes, NEW, broken dep: gnome-python2-gdl-2.25.3-12.fc12.i686 requires libgdl-1.so.2
17:35:40 <adamw> thanks
17:35:46 <adamw> #topic https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=533420
17:35:47 <buggbot> Bug 533420: medium, low, ---, mbarnes, NEW, broken dep: gnome-python2-gdl-2.25.3-12.fc12.i686 requires libgdl-1.so.2
17:36:15 <adamw> #info discussion of 533420 occurs *above* its setting as the meeting topic, please read up
17:37:00 <notting> Oxf13: don't untag 1.9.1.4
17:37:14 <Oxf13> notting: that one is already in the buildroot due to dist-f12 tagging
17:37:19 <notting> ah, ok
17:37:22 <adamw> #agreed 533420 is a release blocker as it's a broken dependency on the DVD spin, a minimum-impact method of sequential rebuilds has been agreed to produce a build that resolves the issue and can be added to the re-spin
17:37:50 <jlaska> yay
17:37:58 <adamw> #action oxf13 to  remove xulrunner from the buildroot, bump/build gnome-python2-extras, tag it, and then put xul back in teh buildroot to build gnome-python2-extras again for the xul update
17:38:23 <notting> we should probalby update the comment in the XR tag request, then (as we said we may take it if we respin)
17:38:48 <adamw> good catch
17:38:59 <Oxf13> notting: good point
17:39:11 <adamw> ok, so, jlaska you wanted to review the matrix? shall i chair you so you can take over for that bit?
17:39:16 <adamw> notting: i'm updating the bug, can you update the tag request?
17:39:30 <jlaska> adamw: either way, just a few bugs to inspect
17:39:40 <adamw> #chair jlaska
17:39:40 <zodbot> Current chairs: adamw jlaska
17:39:42 <adamw> go for it
17:39:43 <notting> adamw: closed
17:40:02 <jlaska> okay, let's start with 2 shrinkage issues
17:40:08 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=523610
17:40:09 <buggbot> Bug 523610: medium, medium, ---, dcantrell, ASSIGNED, error occured during shrink install
17:40:54 <jlaska> we briefly talked about this before I believe ...
17:41:12 <adamw> we've discussed this before, i think jlaska and I agree that partition shrinking is just too dicey to take issues in it as blockers much
17:41:14 <jlaska> Hurry has narrowed down a 100% reproducer (see comment#11)
17:41:38 <jlaska> adamw: that's exactly what I wanted to raise
17:41:51 <jlaska> from our testing so far, I don't get the sense that this area is solid yet
17:41:59 <jlaska> we haven't focused on it as much as we are doing now
17:42:07 <jlaska> so I don't have anything to say these are regressions
17:42:13 <adamw> me either
17:42:22 <jlaska> we have a mix of failures around shrink, along with some successes
17:42:26 <jlaska> haven't pinpointed the commonality yet
17:42:26 <adamw> did we really do much shrinkage testing in the previous releases?
17:42:32 <jlaska> very little
17:42:42 * jlaska looks at https://fedoraproject.org/wiki/Category:Fedora_11_Test_Results
17:43:02 <adamw> i did a very similar test to he rui's - i was using the live installer, and didn't have a /boot partition, but an 18GB / and 2GB swap - and that worked fine
17:43:05 <jlaska> we shipped F11 with shrink failures it seem
17:43:12 <adamw> so...it seems pretty icky area
17:43:16 <jlaska> yeah
17:43:39 <adamw> yeah, i just think that in practice what we have is nowhere near reliable enough to block the release if it's broken. if it's stuffing up existing data i might be worried, but i don't think we have any cases of that?
17:44:05 <jlaska> I don't think we've looked to make sure the previous data is still intact
17:44:09 <jlaska> but that's something to check
17:44:27 <adamw> yeah i think we should add a bug report comment
17:44:33 <Oxf13> I guess it would be prudent to get the anaconda team's take on this
17:44:38 <adamw> good point
17:44:45 <adamw> denise: ping?
17:44:57 <denise> adamw, pong
17:45:10 <adamw> denise: see above - we're discussing shrink failures in anaconda
17:45:21 <Oxf13> I just posed the question in #anaconda too
17:45:52 <adamw> so far jlaska and i are sort of of the opinion that this is messy enough area, and we don't have enough of a proven base of working-ness, not to take shrink failures as blockers generally speaking
17:46:25 <denise> imho, I would not see it as blocking
17:46:29 <adamw> my proposal is more or less that we block only if the function is completely broken - no-one can make it work at all in any circumstance - or for instances where it destroys / corrupts existing data
17:46:37 <adamw> we wanted to know what your team thinks on that
17:47:04 <denise> agree - clumens is off having lunch, he will probably agree
17:47:09 <denise> but should check
17:47:19 <denise> it is tricky to get correct
17:47:32 <denise> and this doenst feel like the time to introduce instability\
17:47:36 <jlaska> and to get it correct ...
17:47:43 <jlaska> we'd invalidate all storage testing done so far
17:47:48 <adamw> yeah, it involves poking delicate bits
17:47:50 <jlaska> ^---> or what denise said :)
17:48:00 <jlaska> so ... I'm not in favor of respining for this stuff
17:48:02 <denise> for something that isnt truly critical
17:48:10 <jlaska> but I wanted to make sure everyone knew where we are
17:48:55 <adamw> ok, so shall we agree for now that the policy on shrink issues is more or less as i outlined above, pending clumens' agreement?
17:49:04 <denise> +1
17:49:16 <jlaska> Oxf13: notting: how do you feel?
17:49:40 <notting> sounds reasonable
17:49:51 <jlaska> alrighty ...
17:50:16 <jlaska> #action denise double checking with clumens for input on installer shrink results
17:50:29 <Oxf13> seems fine
17:50:34 <jlaska> shall I toss an #agreed in at this point?
17:50:54 <denise> yes
17:51:12 <adamw> go for it
17:51:20 <halfline> i do want to just throw a point out there
17:51:25 <jlaska> #agreed present installer shrink bugs are not considered blocker bugs ... addressing them at this time would destabalize storage code
17:51:29 <jlaska> halfline: waddya got?
17:51:31 <halfline> karmic didn't go over so well
17:51:39 <jlaska> true true
17:51:41 <halfline> would be good if made sure f12 was pristine
17:52:03 <halfline> slipping a week to fix even non-critical bugs might be a good idea if they make the release outstanding
17:52:23 <Oxf13> while i agree with that, I'm not willing to slip for an indefinite amount of time to fix a very tricky problem which may introduce any number of regressions
17:52:29 <halfline> provided the fixes are really targeted so they avoid regressions
17:52:32 <adamw> and that's a long way outside the scope of this meeting
17:52:36 <adamw> it's almost a policy issue
17:52:43 <Oxf13> and slipping a week means slipping more than a week due to thanksgiving
17:52:44 <jlaska> halfline: today we're just working the blockers
17:52:51 <halfline> okay
17:52:53 <jlaska> halfline: monday we get to talk about slippage
17:53:08 <jlaska> okay ... next bug ...
17:53:13 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=533350
17:53:14 <buggbot> Bug 533350: medium, low, ---, anaconda-maint-list, NEW, Can't shrink encrypted partition
17:53:17 <jlaska> this is also a shrink bug
17:53:18 <adamw> on the ubuntu thing, i consider that to be more press cycles at work than anything else; it's counter-productive to worry _too_ much about publicity in and of itself
17:53:19 <halfline> just wanted to throw it there as a counter to adamw's proposal earlier
17:53:31 <jlaska> I'll ask kparal to provide the installer logs, I don't see them in the bz
17:53:39 <jlaska> but I think the same decision holds
17:54:01 <denise> and should this be in CommonBugs?
17:54:20 <adamw> denise: i can put a fairly general entry in common bugs to the effect of 'don't rely on shrink'
17:54:22 <denise> if we go the non-blocker route that is
17:54:35 <jlaska> denise: definitely
17:54:37 <denise> thanks adamw
17:54:43 <adamw> and if this is known to be accurate - you can't shrink any encrypted partition - we can definitely document that specifically
17:55:03 <adamw> if you could throw the CommonBugs keyword on there that'd be great, it'll make sure we don't miss it
17:55:10 <jlaska> got it
17:55:42 <jlaska> adamw: I still document CommonBugs I've added ... I'm just sloooower
17:55:43 <adamw> note for both these bugs, we should add comments to check if they have any negative effect on any existing data
17:55:51 <adamw> or if they just fail without touching it
17:56:12 <jlaska> #info ask for feedback as to whether the existing partitions have lost data
17:56:59 <jlaska> okay next up was the dracut-network issue ...
17:57:01 <jlaska> skipping that
17:57:07 <jlaska> #topic https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=533108
17:57:08 <buggbot> Bug 533108: medium, low, ---, xgl-maint, NEW, Unable to switch back and forth between ttys during install
17:57:11 <jlaska> looks like an X issue
17:57:14 <jlaska> nouveau perhaps
17:58:00 <jlaska> others might be familiar with this already ... for me, I'd ask for the versions of xorg-x11-server, kernel and nouveau
17:58:09 <adamw> this could actually well be fixed in the later stuff
17:58:16 <jlaska> right
17:58:17 <adamw> i.e. the stuff we tagged yesterday
17:58:35 <adamw> some of the bugs that got fixed in the last two days would have manifested like this
17:58:43 <adamw> so we should ask him to re-test with the RC build or later
17:58:49 <jlaska> okay, I'll update the bz asking for updated testing from Hurry
17:58:58 <jlaska> anywhere to track these while we are waitin
17:58:59 <jlaska> g
17:59:09 <jlaska> should we add this to the list awaiting feedback?
17:59:23 <adamw> i guess
17:59:32 <adamw> gonna CC myself on this one so i don't lose it
17:59:45 <jlaska> wanna add to X blocker list?
17:59:49 * jlaska will add a comment to the bz
18:00:00 <adamw> not really, as it's likely a dupe of a bug that's already on there
18:00:05 <jlaska> okay
18:01:25 <adamw> i couldn't tell which without some logs but frankly it's more useful to get him to test with rc and confirm it's fixed than worry about exactly which bug it is
18:01:52 <jlaska> agreed
18:02:04 <adamw> her, sorry
18:02:16 <jlaska> #agreed request updated testing from Hurry using latest kernel and xorg-x11-server fixes
18:02:39 <adamw> lack of sleep is affecting my gender-recognition centres =)
18:02:47 <jlaska> :D
18:02:51 <jlaska> alright, next up
18:02:52 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=533123
18:02:53 <buggbot> Bug 533123: medium, low, ---, anaconda-maint-list, CLOSED DUPLICATE, reboot does not work when install from vnc which start from telnet
18:03:06 <jlaska> this is marked as a dupliate to bug#525615
18:03:07 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=525615 medium, low, ---, clumens, NEW, system can not automatically reboot after exit installer -f12 beta TC
18:03:39 <jlaska> the failure case here is that the installer doesn't exit the same way it did in F-11 after saving a traceback
18:03:58 <jlaska> I think this is relatively low impact
18:04:22 <jlaska> I think we just need guidance from clumens on expectations and what might have caused the change
18:04:25 <jlaska> https://bugzilla.redhat.com/show_bug.cgi?id=525615#c12
18:04:26 <buggbot> Bug 525615: medium, low, ---, clumens, NEW, system can not automatically reboot after exit installer -f12 beta TC
18:05:21 <denise> jlaska agreed - we need clumens for this one, aalthough there are a lot of dups
18:05:50 <jlaska> denise: I think we finally narrowed this one down, and I don't think it's severe.  Just a changein behavior
18:05:58 <adamw> that mostly worries me in the sense it means others are hitting exceptions =)
18:06:11 <jlaska> adamw: we were forcing it with this test
18:06:18 <jlaska> https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_bugzilla
18:06:33 <denise> l and this was a meh problem, right?
18:06:35 <adamw> 532607 wasn't. but, meh.
18:06:43 <adamw> this issue in itself, yeah, not a blocker.
18:06:47 <jlaska> adamw: you're right, didn't start out that way
18:06:55 <jlaska> denise: it might be related to the python-meh change, not sure
18:07:53 <jlaska> #agreed 525615 is change in behavior during reboot after a handled exception.  Agreed this isn't a blocker list.  Clumens will look into whether python-meh may have introduced the changed behavior
18:08:05 <jlaska> #topic open floor
18:08:08 <jlaska> that's all I have
18:08:29 <Oxf13> I got nothing else.
18:09:35 <jlaska> alright, so we are go for RC.2 then?
18:09:47 <jlaska> anything we need to summarize around RC.2 ... who has the ball etc...?
18:10:42 <adamw> i'm a go for rc.2 yep
18:10:52 <Oxf13> I've got the gnome-python2-extras build going right now
18:11:11 <adamw> as a general note there was no wailing and gnashing of teeth on the forums that i can see surrounding the latest bits, so that's encouraging
18:11:15 <Oxf13> I'll combine that with the lynx build, and the change in the fedora-install-fedora.ks file to include dracut-network
18:11:34 <Oxf13> with those three changes, I think we're set to do RC.2.
18:13:09 <jlaska> Oxf13: okay ... I'll give Liam a heads up
18:13:23 <jlaska> it'll unfortunately take a lot of time for he & Hurry to sync the ISO's
18:13:35 <Oxf13> right
18:14:01 <adamw> i think any RC1 testing should be valid though
18:14:11 <warren> adamw: I'm aiming for 114%.
18:14:19 <jlaska> yeah, I've got a discussion going with him now on how to determine what testing to reset
18:14:38 <adamw> warren: 114% fedora 12 approval rating? :)
18:14:43 <jlaska> looks like I have access to download the ISO's for him ... that will save time
18:15:00 <jlaska> Oxf13: what's your ETA for RC.2?
18:15:00 <adamw> #agreed everyone is go to spin RC.2
18:15:00 <jlaska> 7 hours from now?
18:15:03 <Oxf13> jlaska: probably 2~3 hours
18:15:29 <jlaska> oh wow, okay
18:15:39 <warren> is alt.fp.org accessible via rsync?  i could download the diff between RC.1 and RC.2 faster...
18:15:40 <Oxf13> we don't have to get mash involved
18:15:40 <jlaska> same same dirname etc... with just s/2/3/ ?
18:15:53 <Oxf13> warren: it is, if you have ssh access and can make some tunnels
18:15:56 <Oxf13> jlaska: yep
18:15:57 <warren> ah
18:15:58 <warren> ok
18:16:47 <jlaska> Oxf13: thx, Liam and Hurry should have the ISO's for them when they arrive Monday morning
18:16:54 <Oxf13> k
18:17:01 <jlaska> adamw you started this puppy ... want the honor of ending it too?
18:18:25 <adamw> alrighty
18:18:32 <adamw> now ending the longest ever really short meeting =)
18:18:45 <adamw> thanks all for coming! been a long week
18:18:46 <adamw> #endmeeting