15:12:15 <jlaska> #startmeeting F-13-Blocker bug review
15:12:15 <zodbot> Meeting started Fri Apr 16 15:12:15 2010 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:12:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:12:23 <jlaska> #meetingname f-13-blocker-bug-review
15:12:24 <zodbot> The meeting name has been set to 'f-13-blocker-bug-review'
15:12:33 <jlaska> #chair adamw
15:12:33 <zodbot> Current chairs: adamw jlaska
15:12:42 <jlaska> #topic Gathering critmass ...
15:12:54 * adamw eating a muffin to help with the critmass
15:13:06 <jlaska> we have anaconda representation today too ... yay dlehman!
15:13:25 <jlaska> Oxf13 around?
15:13:27 * dlehman raises coffee mug in toast
15:14:45 <jlaska> alright ... let's get moving and we can pull in others as needed
15:14:58 <jlaska> #topic Why are we here?
15:15:17 <adamw> quick, someone call descartes
15:15:27 <jlaska> LOL!
15:15:38 <jlaska> Most likely obvious now, but for those reading the minutes on a Saturday afternoon ...
15:16:03 <jlaska> #info Review the list of F13Blocker bugs to determine whether they put the Fedora 13 release criteria at risk
15:16:07 <jlaska> #link https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria
15:16:46 <jlaska> #link F13Blocker bugs (sorted by component) - http://tinyurl.com/y4pa97n
15:16:55 <jlaska> well ... improper use of link ... but good enough
15:17:00 <jlaska> shall we get started?
15:17:31 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=569469
15:17:32 <buggbot> Bug 569469: medium, medium, ---, dlehman, NEW, ValueError: Cannot remove non-leaf device 'vda5'
15:18:16 <adamw> so this is a random specific raid layout issue?
15:18:44 <jlaska> I think it's the combination of RAID on top of an existing RAID partition scheme?
15:18:52 <jlaska> or perhaps just general pre-existing partition issue
15:19:26 <adamw> it does seem like a blocker according to the criteria
15:19:48 <adamw> i think at fudcon we pretty much agreed that any specific bug we're aware of with a valid partition layout ought to be fixed
15:19:55 <jlaska> yeah ...
15:20:04 <jlaska> #info affects final criteria "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"
15:20:21 <jlaska> the only thing I'm not clear on is if this is a common issue, or just specific to the exact pre-existing partition setup
15:20:29 <jlaska> I'd need dlehman's help for that
15:20:49 <jlaska> should we +1 and move on ... or continue discussing impact?
15:21:24 <dlehman> assuming the reproducer indeed reproduces, I vote to +1
15:21:46 <jlaska> I can queue this up for retesting on that same guest ... I still have it around
15:22:43 <jlaska> oh actually ... the more I read my own writing ...
15:23:01 <jlaska> I think this is related to attempting to create an invalid RAID setup
15:23:02 <jlaska> Attempt to create a RAID5 device ... it should fail since there are only 2
15:23:05 <jlaska> RAID members
15:23:12 <jlaska> then go back and continue making partition edits ... BOOM
15:23:19 <jlaska> I'll see if I can retest
15:23:41 <jlaska> #action jlaska will retest to confirm there is a consistent reproducer
15:24:07 <jlaska> #agreed Attempt to create a RAID5 device ... it should fail since there are only 2If consistently reproduces, remains as a F13Blocker
15:24:08 <adamw> sounds good
15:24:11 <jlaska> RAID members
15:24:15 <jlaska> #unfo
15:24:17 <jlaska> #undo
15:24:18 <jlaska> :)
15:24:19 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x2b03b2922190>
15:24:26 * jlaska realigns to home keys
15:24:43 <jlaska> #agreed 569469 - If consistently reproduces, remains as a F13Blocker
15:25:08 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=534066
15:25:09 <buggbot> Bug 534066: medium, low, ---, anaconda-maint-list, NEW, Anaconda does not assign correct root partition to boot windows
15:25:35 <jlaska> thanks to beland, we have a nice impact statement already
15:26:32 <jlaska> dlehman: Is Hans still in need of feedback from clumens on this?
15:27:25 <dlehman> seems to have stalled on that, yes
15:27:27 <adamw> we were quite active on this issue post-f12, but it seems like it's got lost in the shuffle a little
15:27:28 <jlaska> #info anaconda incorrectly sets the windows restore partition as windows partition
15:28:07 <jlaska> Seems to meet the criteria
15:28:10 <jlaska> +1 from me
15:28:25 <adamw> i'd definitely consider this a blocker, it's a bit ugly and should really be fixed. most systems ship with restore partitions these days.
15:28:33 <jlaska> yeah
15:29:30 <dlehman> no objection here
15:30:10 <adamw> so we should poke clumens to get the process restarted i guess
15:30:14 <jlaska> #agreed 534066 - remains as a F13Blocker - most systems ship with restore partitions and this would cause confusion when installing F13 along-side such systems
15:30:24 <jlaska> looks like dlehman has already started that
15:30:46 <jlaska> #action dlehman will discuss solutions for 534066 with clumens and hansg
15:31:08 <jlaska> stop me if I'm going to fast (and since I type slow ... I don't think that will be an issue)
15:31:08 <dlehman> clumens has agreed to hans' proposal and they'll move forward to sort out the details
15:31:16 <jlaska> cool, thanks dlehman
15:31:54 <jlaska> #info anaconda-devel agreement reach on hansg suggestion ... should start moving forward
15:31:58 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=577501
15:31:59 <buggbot> Bug 577501: medium, low, ---, msivak, ASSIGNED, rebuild fails for anaconda-13.36
15:32:24 <jlaska> anaconda-13.36 fails to compile under
15:32:24 <jlaska> gcc-4.4.3-8.fc13.x86_64
15:32:50 <jlaska> so this would impact self-hosting of Fedora
15:32:52 <jlaska> ?
15:33:05 <jlaska> afaik, we don't have specific criteria around this, do we?
15:33:17 <adamw> we don't no. i think ftbfs has traditionally been a release blocker though?
15:33:24 <dlehman> this patch will go in whether or not its a blocker, so...
15:33:47 <jlaska> okay, that solves that
15:33:54 <jlaska> -    int i, rc, dir = 1;
15:33:54 <jlaska> +    int i, rc = LOADER_NOOP, dir = 1;
15:34:34 <jlaska> #question Are FTBFS bugs considered release blockers?
15:34:50 <jlaska> #help Are FTBFS bugs considered release blockers?
15:34:59 <notting> i doubt it. although they can block release blockers.
15:35:19 <jlaska> "#  FTBFS blocks Target tracker for next release "
15:35:27 * jlaska reading http://fedoraproject.org/wiki/FTBFS
15:35:35 <adamw> okay. so we should bump it to target.
15:35:45 <jlaska> from what I'm seeing, yeah
15:36:10 <jlaska> objections?
15:36:22 <jlaska> more bookkeeping really, since it's going in
15:36:44 <adamw> let's just do it and move on
15:36:44 <jlaska> #agreed According to http://fedoraproject.org/wiki/FTBFS, 577501 will be moved to F13Target
15:36:56 <jlaska> #info dlehman notes this will be pulled into future F13 anaconda build
15:36:58 <adamw> jlaska: are you making the changes as we go or would you like me to?
15:37:19 <jlaska> adamw: go for it
15:37:43 <jlaska> you're usually much faster for that ... but we can divide them up as we go
15:37:49 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=568528
15:37:50 <buggbot> Bug 568528: medium, low, ---, msivak, ASSIGNED, firewall --disabled still produces a blocking /etc/sysconfig/iptables
15:38:22 <jlaska> I don't know if we have a specific criteria for this, but I'd support fixing this for F13
15:39:10 <jlaska> I think it would mean that any kickstart installs with "firewall --disabled" end up having a firewall enabled (blocking remote access)
15:39:59 <adamw> that does seem like something that ought to block the release, but we don't have a criteria for it. should we add one?
15:40:25 <adamw> er, a criterion* . d'oh.
15:40:29 <jlaska> heh
15:42:09 <adamw> draft: "With the correct install configuration, it should be possible to make an installed system immediately remotely accessible (you should be able to install with a secure remote access service active and unblocked by firewall-type mechanisms)"
15:42:47 * jlaska had a visitor
15:43:18 <jlaska> yeah, I like that
15:43:34 * jlaska wonders if there is tie in with any existing SELinux criteria
15:43:45 <jlaska> anyway, should we queue that up for post-meeting action?
15:43:54 <adamw> yeah
15:44:04 <adamw> i think we can accept this as a provisional blocker on the basis we'll add a criterion
15:44:37 <jlaska> #action adam proposed a new release criterion for capturing blocking SSH firewall as found in 568528
15:44:56 <jlaska> #agreed 568528 accepted as a provisional blocker ... new release criterion will be drafted
15:45:07 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=568219
15:45:08 <buggbot> Bug 568219: medium, medium, ---, dlehman, ASSIGNED, PartitionException: Too many primary partitions.
15:45:42 <jlaska> this came from Alpha and Beta testing ... seems rhe can consistently hit this
15:46:09 <jlaska> and we have a autofiled bug linked from earlier this week
15:46:17 * dlehman +1 this one
15:46:46 <jlaska> +1 from me too
15:47:07 <adamw> yeah, +1
15:47:08 <jlaska> this touches on the catch-all criterion of workable partition scheme
15:47:20 <adamw> looks like you guys have a handle on why this happens too, dlehman?
15:47:55 <jlaska> #agreed 568219 - a valid F13Blocker bug impacting a reasonable partitioning layout
15:48:06 <dlehman> more or less -- once I reproduce I don't expect it to take long to see what's happening
15:48:42 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=566259
15:48:43 <buggbot> Bug 566259: medium, low, ---, mgracik, ASSIGNED, Segfault when disconnecting telnet client during telnet install
15:48:51 <dlehman> since the extended partition is itself a hack, there are of course several hacks to accommodate it
15:49:32 <adamw> is this set as a blocker just because you cloned it from a blocker?
15:49:38 <adamw> it doesn't seem like a blocker in itself
15:49:41 <jlaska> oh could be
15:49:48 <jlaska> yeah, I don't think this fits any criteria
15:50:33 <adamw> so, -1
15:50:43 <jlaska> we have an Alpha criteria on text installs, but to my understanding, while 'telnet' does do a text install ... it's different in how we test the installer
15:51:05 * notting repeats the normal response to this bug of "we still ship telnet install?"
15:51:11 <jlaska> notting: exactly!
15:51:18 <jlaska> dlehman: please remove this in F14 :D
15:52:03 <adamw> well, also, this is hardly the install is broken, but 'it crashes when i do that'. so, y'know, don't do that. afaics.
15:52:10 <jlaska> #agreed 566259 - not a blocker, only occurs when disconnecting from a telnet install
15:52:14 <dlehman> I thought we needed to keep it for a certain kind of machine that looks like a refrigerator
15:52:37 <notting> dlehman: vnc doesn't work there? (only mildly trolling)
15:52:41 <jlaska> dlehman: s390 telnet is different from booting with "telnet" .. .at least behaves different
15:53:06 <dlehman> ok
15:53:18 <jlaska> I could be wrong, haven't done a mainframe install in a bit
15:53:20 <dlehman> and now that we also have ssh it seems even more useless to keep telnet
15:53:26 <jlaska> right ...
15:53:34 <Oxf13> I'm here.
15:53:40 <adamw> hey oxf13
15:53:41 <jlaska> #help Can we remove 'telnet' install support?  Please?
15:53:42 <Oxf13> hrm, was this an hour earlier than I thought it was?
15:53:52 <adamw> yeah, jlaska sneakily rescheduled it
15:53:59 <jlaska> Oxf13: yeah, I did a meeting time shuffle
15:54:09 <Oxf13> is that a permanent move, or just this week?
15:54:34 <jlaska> I did it just for today, but open to making it permanent.
15:54:43 <jlaska> it's probably harder for you west coasters though
15:54:48 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=531629
15:54:49 <buggbot> Bug 531629: medium, low, ---, anaconda-maint-list, ASSIGNED, RuntimeError: Returning partitions to state prior to edit failed
15:55:06 <dlehman> +1
15:55:27 <adamw> to be clear, this is not PPC-specific, right?
15:55:35 <jlaska> it used to be, but seems not anymore
15:55:45 <Oxf13> jlaska: starting at 8am pacific isn't too terrible, I Just need to know ahead of time (:
15:56:14 <dlehman> especially given simplicity of reproducer in comment 7 this looks like a blocker
15:56:19 <jlaska> Oxf13: agreed, I only sent out the meeting announce yesterday ... I should have done it sooner with the time change
15:56:42 <jlaska> dlehman: oh yeah, that's a more straightforward reproducer
15:57:09 <dlehman> hopefully they are indeed the same failure
15:57:34 <jlaska> well, at least the tracebacks match
15:57:47 <adamw> looks like a +1 to me too then
15:58:10 <jlaska> #info 531629 - impacts the "reasonable" partition criteria, use default partition layout, edit /boot size
15:58:20 <Oxf13> yeah, +1 here
15:58:53 <jlaska> #agreed 531629 - is a valid F13Blocker
15:59:29 <jlaska> MODIFIED anaconda bugs time
15:59:32 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=581820
15:59:33 <buggbot> Bug 581820: medium, medium, ---, hdegoede, MODIFIED, NameError: global name 'info' is not defined
15:59:53 <jlaska> not sure what the reproducer is
16:00:26 <jlaska> but looks straightforward
16:00:52 <adamw> are there any bugs on the modified list we really need to worry about?
16:01:13 <jlaska> ooh, I like that suggestion!
16:01:41 <adamw> the only question that really matters is who's going to close them
16:01:43 <jlaska> a bunch from Alpha and Beta testing, so I'm happy with those
16:02:04 <jlaska> we should queue these up for testing
16:02:26 <jlaska> I can go through and add needinfo? to each asking for feedback with the latest anaconda (if that's available in nightly Branched)
16:03:01 <jlaska> one or two I've already tested as updates.img ... so that's good
16:04:11 <jlaska> objections if we move on to the next non-MODIFIED bug in the list?
16:05:00 <adamw> sounds fine to me
16:05:06 <Oxf13> I don't have any objections, but I also haven't noticed a new anaconda since beta
16:05:33 <jlaska> oh yeah  ... Oxf13, dlehman: fyi we have a install acceptance run on the schedule for next week
16:05:45 <jlaska> perhaps we can coordinate that with testing these MODIFIED bugs
16:05:55 <jlaska> I'll ticket and we can follow-up outside of this meeting
16:06:41 <jlaska> #agreed Skip remaining MODIFIED anaconda blocker bugs
16:06:50 <jlaska> #action jlaska to ping each MODIFIED anaconda bug for test feedback
16:07:00 <jlaska> okay, we're done with anaconda bugs, thanks dlehman
16:07:03 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=577004
16:07:04 <buggbot> Bug 577004: medium, low, ---, metherid, ON_QA, "The folder contents could not be displayed" error on clean F13 Beta TC1 install
16:07:54 <jlaska> adamw this is your baby
16:08:17 <jlaska> I assume this is from the desktop menu sanity test
16:08:21 <adamw> oh whoops, didn't get to testing it yet
16:08:38 <adamw> yeah, it's a failure of the most extensive desktop test, which basically says all apps installed by default must pass a smell test
16:09:03 <jlaska> no gangrenous apps!
16:09:25 <jlaska> ""All
16:09:25 <jlaska> ""applications listed under the Applications menu must withstand a basic
16:09:29 <jlaska> functionality test and not crash after a few minutes of normal use."
16:09:32 <adamw> yep, that's it
16:09:50 <jlaska> no objections here ... considering this is crashing with the default setup, no local site configuration involved
16:09:52 <adamw> it's slightly vague, but i'd consider an error message as soon as you open the preferences a failure of 'basic functionality'
16:09:53 <jlaska> +1
16:10:05 <adamw> they say it's fixed anyway, i'll test and confirm
16:10:20 <jlaska> #action adamw to test and confirm fix for 577004
16:10:37 <jlaska> I'm going to agreed on this one since it's already ON_QA, if it bumps back out we'll revisit next week
16:11:06 <jlaska> #agreed 577004 - is a valid F13Blocker resulting in a crashing app after a default install with no local system configuration
16:11:21 * jlaska skips 2 Tracker bugs
16:11:22 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=576060
16:11:23 <buggbot> Bug 576060: medium, medium, ---, esandeen, ASSIGNED, FSResizeError: ('resize failed: 1', '/dev/sda2')
16:12:37 <jlaska> so if I understand from esandeens comment, there are no plans to pull this in for F-13
16:12:48 <jlaska> and a patch to work around the problem is now in F-13 anaconda
16:13:45 <jlaska> so ... I'd propose removing this from F13Blocker, it seems the failing test shoudl be resolved now with the anaconda fix bclane added to f-13 anaconda
16:14:06 <adamw> i think we should get confirmation from he rui on exactly how it behaves now
16:14:11 <Oxf13> hrm, I'd say clone for rawhide
16:14:15 <jlaska> dlehman: actually ... would the fix for this need to come into the f13-branch?
16:14:19 <Oxf13> then set hte F-13 one to modified
16:14:25 <Oxf13> to be verified after we get a new build.
16:14:36 <Oxf13> since ideally we wouldn't be taking this workaround forward into F14
16:14:41 <jlaska> agreed to both adamw and Oxf13
16:14:54 <jlaska> http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=96445547da4dd5d92aa37a46b95472d63671888f
16:15:10 <Oxf13> yeah that's after the beta build, and we don't have a newer build yet
16:15:31 <jlaska> yes, looks like this is fixes in anaconda-13.37.3 (see bug#578955)
16:15:32 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=578955 medium, low, ---, bcl, CLOSED NEXTRELEASE, Re-Check minimum size of partition after running fsck on it
16:15:45 <jlaska> Oxf13: right, sorry ... just making sure it was in the f13-branch
16:16:20 <jlaska> #action rhe to confirm the workaround resolves the reported problem in bug#578955
16:16:27 <Oxf13> um
16:16:30 <Oxf13> 13.37.3 doesn't exist
16:17:03 <jlaska> I'm not worried
16:17:15 <jlaska> it's in f13-branched and should land in the next anaconda build I think
16:17:27 <jlaska> f13-branch commit http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=85f29b805c31357bd3a91397e2161d4866647cf5
16:17:51 <jlaska> as for blocker criteria ...
16:18:09 <jlaska> I think this touches on "workable partition layout", nothing crazy going on here from what I can tell
16:18:36 <jlaska> well ... I take that back ...
16:18:47 <jlaska> it's not common, but not terribly unusual
16:19:00 <Oxf13> well, trying to resize and having a dirty partition isn't hard to come by
16:19:02 <jlaska> installing on a system with a dirty ext partition header
16:19:05 <jlaska> yeah
16:20:51 <jlaska> #action jlaska to clone 576060 for expected F-14 anaconda fix
16:21:19 <jlaska> #agreed 576060 is a valid F13Blocker involving partition resize of dirty partitions
16:21:28 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=579515
16:21:29 <buggbot> Bug 579515: medium, medium, ---, jmagne, NEW, ESC still requires ifd-egate.
16:22:27 <Oxf13> I'm hard pressed to count this as a blocker
16:23:32 <adamw> sorry, back...
16:23:35 <jlaska> yeah, it's not clear how this would impact the criteria
16:23:52 <adamw> it's an inherited blocker
16:23:54 <jlaska> rrelyea added it to the list
16:24:04 <adamw> it doesn't block f13blocker directly; it blocks https://bugzilla.redhat.com/show_bug.cgi?id=567325 which blocks f13blocker
16:24:05 <buggbot> Bug 567325: medium, low, ---, rrelyea, NEW, ifd-egate uses deprecated udev rules syntax
16:24:09 <jlaska> ah
16:25:00 <adamw> so we want to get rid of ifd-egate , which is causing warnings on startup (which I think we do have a criteria for)
16:25:12 <adamw> and esc requiring it was causing it to be pulled in to the images
16:25:53 <jlaska> #  All services in a default install must start properly
16:26:53 <jlaska> is esc included in a default install?
16:26:55 * jlaska checking
16:28:00 <adamw> it's ifd-egate that's causing the problems
16:28:10 <jlaska> adamw: are you proposing this is a blocker?
16:28:11 <adamw> given the comments on the initial bug, _something_ that requires it must be in there...
16:29:10 <jlaska> alrighty
16:29:36 <adamw> hold on, lemme do some sleuthing
16:29:52 <jlaska> esc is listed as optional in comps.xml GNOME Desktop ...
16:30:30 <adamw> i think coolkey may actually still be the problem
16:30:41 <jlaska> <packagereq type="default">coolkey</packagereq>
16:30:46 <jlaska> in @base
16:30:57 <adamw> there's a build that removes the dep on ifd-egate
16:30:57 <adamw> http://koji.fedoraproject.org/koji/buildinfo?buildID=158058
16:31:03 <adamw> but it doesn't seem to have been submitted as an update
16:31:26 <jlaska> let's move on if we can ...
16:31:31 <jlaska> ask for more info in the bug report?
16:31:39 <adamw> no, it's okay, i understand this now
16:31:47 <adamw> the current way the bugs are set up is correct
16:31:57 <adamw> i'll update the bugs
16:31:59 <jlaska> so this stays on the list because it impacts spewage on boot with coolkey
16:32:17 <jlaska> hit me with an #info
16:34:33 <adamw> #info the fixed esc and coolkey builds need to be submitted as updates
16:34:54 <adamw> #action adamw to track 567325 and 579515 to ensure the fixed builds are sent through as updates and ifd-egate is removed
16:35:37 <jlaska> thx
16:35:44 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=549093
16:35:45 <buggbot> Bug 549093: high, high, ---, wb8rcr, ASSIGNED, Release notes cannot be viewed on the KDE spin
16:36:18 <jlaska> last updated in 2009-12-22
16:36:59 <jlaska> the stale-ness doesn't bode well here, but this does seem to pose a problem for any KDE users
16:37:21 <adamw> yeah. we're currently in an icky state with non-default desktops. we don't officially apply the criteria to them.
16:37:35 <adamw> i'd like to do that for f14, but in this case, i guess it's back to being a judgment call
16:37:55 <jlaska> let's post a comment into the bz and see what's the latest on this issue
16:38:08 <adamw> sounds good
16:38:24 <adamw> i'll do it
16:39:48 <jlaska> ooh, you beat me (collision)
16:40:11 <jlaska> #agreed 549093 hasn't been updated since 2009-12, need more info from assignee to assess impact to release criteria
16:40:22 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=571900
16:40:23 <buggbot> Bug 571900: medium, low, ---, jmccann, NEW, Keyboard mapping not correct (USA instead of Belgium) when first login after install Fedora 13 Alpha -
16:41:11 <jlaska> still in NEW, but the reporter indicates the bug has been solved
16:41:17 <jlaska> have there been any fixes to address the problem
16:41:41 * jlaska checks gdm in koji
16:42:36 <adamw> i think the report is a little confused
16:42:40 <jlaska> mclasen isn't on #fedora-devel at the moment, and I don't see this bug referenced in any builds
16:42:45 <adamw> michel and petri don't appear to be reporting exactly the same problem
16:43:45 <adamw> we could ask them for a clarification/update?
16:44:18 <jlaska> yup
16:44:35 <adamw> done
16:44:43 <jlaska> I don't think we have specific criteria on the list for i18n ... butthat's already something on the QA retrospective
16:46:01 <jlaska> #action adamw requesting clarification in 571900 - mixed reports of success and failure in the bug
16:46:10 <adamw> arguably all the criteria we have should apply in any language.
16:46:22 <jlaska> all supported languages
16:46:26 <jlaska> not all of them are fully translated?
16:46:42 <adamw> yeah, that's what I meant.
16:46:48 <jlaska> okay
16:46:49 <adamw> though we could probably write in something more specific to make it clear
16:47:10 <jlaska> #help how to find the list of fully supported languages
16:47:22 <jlaska> so let's leave this on for review next week
16:47:24 <jlaska> objections?
16:48:41 <jlaska> adamw: Oxf13 I've got a conflict I need to prep for ... are you guys interested in proceeding, or rescheduling for the remaining bugs (kernel, preupgrade, PK, NM, xorg*)?
16:48:59 <Oxf13> since I have a meeting in 10 minutes, probably best to reschedule
16:49:13 <adamw> reschedule to when?
16:49:15 <jlaska> #agreed 571900 will remain on the list awaiting clarification from report
16:49:20 <adamw> later today?
16:50:06 <jlaska> I think I should be good for 3PM EDT (noon pacific)?
16:51:07 <jlaska> sorry gents, I've got to run
16:51:27 <jlaska> adamw: you have #chair, can you set #topic to when we'll resume ... or #endmeeting and I can reschedule for next week
16:51:45 <adamw> noon PST works for me
16:51:50 <adamw> oxf13 does that work for you?
16:53:56 <Oxf13> hrm, that's my lunch hour, but I supposed I can eat and work
16:54:36 * adamw lunches at 1
16:54:36 <adamw> :)
16:54:44 <adamw> we accept crumb-y comments
16:55:08 <adamw> let's say we'll be back in 2 hours then
16:55:22 <adamw> #topic blocker meeting: on hold till 3pm EDT / 12pm PDT
16:56:41 <Oxf13> I could also delay lunch to one as well.
16:57:28 <notting> Oxf13: are we doing rel-eng or no?
16:58:04 <Oxf13> yeah, I suppose
16:58:07 <Oxf13> hopefully quickly
18:57:44 <jlaska> meeting starting back up in a few minutes ...
18:59:04 * adamw cranking up the gears
19:00:21 <jlaska> alrighty ... let's see where we were ...
19:00:36 <adamw> 571900 was the last
19:00:54 <jlaska> Oxf13: are you desk dining today?
19:01:00 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=568106
19:01:01 <buggbot> Bug 568106: medium, low, ---, pjones, NEW, Unable to enter grub menu in F-13-Alpha with console=ttyS0
19:01:06 <Oxf13> oh yeah.
19:01:09 <Oxf13> we're back.
19:01:19 <Oxf13> this bug again.
19:01:23 <jlaska> yeah
19:02:03 <jlaska> I still think this is something to consider for the final release.  Same with previous criteria, there's nothing specific that mentions this
19:02:28 <jlaska> it's all about attempting to enter the grub menu when booting with serial console
19:02:56 <Oxf13> yeah, I agree
19:02:57 <adamw> i really find it hard to judge this. how common is this scenario?
19:03:06 <Oxf13> server world, fairly common
19:03:26 <jlaska> when reviewed for the Beta, jforbes (virt) recommended moving this to Final
19:03:44 <jlaska> since that's when this most impacts my tests ... doing virt-installs
19:04:45 <Oxf13> yeah, we just have to get focus on it.
19:04:51 <jlaska> it might not even be virt in the end, but I think we need to get eyes on it
19:05:39 <jlaska> I'll take action item to talk to pjones after and setup the reproducer
19:06:02 <jlaska> #action jlaska to ping pjones to provide reproducer for 568106
19:06:15 <jlaska> I hope we don't have to review this again next week
19:07:16 <jlaska> keep on the list for next week ... adamw you sound liked a 'maybe' on the blocker-ness of this issue
19:07:27 <adamw> more of a 'don't really know'
19:07:32 <jlaska> okay
19:07:38 <adamw> i leave it up to you two since you seem to have a better idea
19:07:51 <adamw> it would be nice to relate it to the criteria, though, even if it's the escape clause
19:08:00 <jlaska> #info expected impact on server and non-graphical virt guests
19:08:19 <jlaska> #agreed revisit next week, hopefully after devel review
19:08:31 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=567325
19:08:32 <buggbot> Bug 567325: medium, low, ---, rrelyea, NEW, ifd-egate uses deprecated udev rules syntax
19:08:37 <adamw> we already talked about this
19:08:38 <jlaska> adamw: I believe you already addressed this?
19:08:39 <adamw> due to its child bug
19:08:40 <adamw> yup
19:08:58 <jlaska> #agreed addressed earlier (see log)
19:09:01 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=577482
19:09:02 <buggbot> Bug 577482: medium, low, ---, rdieter, ON_QA, X server hogs the CPU
19:09:24 <Oxf13> ON_QA
19:09:50 <jlaska> anything else to discuss ... or next
19:10:23 <jlaska> for the remainder of the list ... I'm going to skip MODIFIED and ON_QA
19:10:47 <adamw> i've been following this one, it's a slightly icky KDE issue, does look like it's fixed though.
19:10:49 <jlaska> #action 577482 - ON_QA awaiting retest
19:11:13 <jlaska> adamw: anything else to add for this one?
19:11:59 <adamw> nup
19:12:03 <jlaska> alright, next up ...
19:12:10 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=577059
19:12:11 <buggbot> Bug 577059: medium, low, ---, kernel-maint, NEW, Failure while swapping install discs on KVM guest (F12 virt host)
19:12:30 <jlaska> I asked jforbes to lurk for a few upcoming bugs, I think this might be a good one for his input
19:13:24 <jlaska> in QA, we've relied on using virt-manager to confirm multiple CD disc installs
19:13:27 <Oxf13> cd switching in virt used to be a laugh, is this expected to work now?
19:13:56 <jlaska> good question
19:14:14 <jforbes> It is not known to be easy, but the reattach shoudl work
19:14:37 <jforbes> I would still consider this a blocker. I will make it a priority
19:14:47 <adamw> it seems a +1 to me based on the criteria
19:15:06 <Oxf13> yeah, if it's supposed to work, I'm +1 on a blocker
19:15:38 <jlaska> #agreed 577059 is a F13Blocker - virt installs with multiple CD's are expected to work
19:16:15 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=560628
19:16:16 <buggbot> Bug 560628: medium, low, ---, kernel-maint, NEW, KMS: Disturbed display with 2.6.32.x / 2.6.33.x
19:17:17 <Oxf13> no input from the maintainer so far
19:18:10 <jlaska> so this is intel "852GM/855GM"
19:18:25 <adamw> that's one of the annoying old chipsets that just won't die
19:18:26 <jlaska> this needs ajax input?
19:18:33 <adamw> 8xx generally has worse support than later chipsets
19:18:36 <adamw> yup, ajax would be the guy
19:19:41 <jlaska> okay, needinfo'd ajax
19:20:07 <jlaska> adamw: is that a small set of chipsets or something we'd consider blocking the release for?
19:20:19 <adamw> this is a judgment call as all X bugs are...
19:20:37 <adamw> i'd want at least basic 2D to run on _all_ Intel chipsets. if this is a general issue affecting 855s i'd want it as a blocker
19:20:44 <adamw> but right now we only really know it's hitting mamoru
19:20:51 <Oxf13> I'd like to get input from the maintainer as to if it's a blocker ornot
19:20:52 <adamw> hold a sec, lemme look at the intel test matrix
19:21:53 <adamw> we have one other report from an 855 on the test day, https://fedoraproject.org/wiki/Test_Day:2010-04-15_Intel
19:22:02 <adamw> cschwengler has an 855GM and marks basic test as PASS
19:22:18 <adamw> in fact, passes for everything except glx. so i guess he doesn't have this issue
19:23:21 <adamw> not much data, though. i don't see any other 8xx generation tests, in fact.
19:23:42 <jlaska> #info one 855GM PASS result in https://fedoraproject.org/wiki/Test_Day:2010-04-15_Intel
19:23:58 <adamw> so it would definitely be nice to see if ajax has a feel for the impact of this
19:24:10 <jlaska> #agreed need input from ajax to determine impact
19:24:14 <adamw> he seems active in -devel right now, should i try to pull him in?
19:24:26 <jlaska> sure let's dooeeet
19:25:35 <adamw> i pinged, let's give him a minute or two
19:26:50 <adamw> guess he's busy. let's just go with the needinfo in the bug for now
19:26:54 <adamw> if he comes in later we can go back to it
19:27:29 <jlaska> alright..
19:27:38 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=560087
19:27:39 <buggbot> Bug 560087: medium, low, ---, mchristi, NEW, [ INFO: possible circular locking dependency detected ] - iscsid/622 is trying to acquire lock:
19:28:18 <Oxf13> well it's got some movement
19:28:47 <jlaska> iSCSI has been problematic this release
19:29:12 <jlaska> due to this issue, and 577803
19:29:18 <jlaska> so ... blocker ?
19:29:20 <adamw> which criterion does this affect exactly?
19:29:28 <jlaska> my testing is old, and needs an update
19:29:34 <adamw> if the actual operation you're trying to do works, then i'm not convinced it's a blocker
19:30:06 <jlaska> #action jlaska will retest iSCSI during install https://fedoraproject.org/wiki/QA:Testcase_Anaconda_ISCSI_No_Authentication
19:30:19 <jlaska> adamw: yeah, I need to refresh my memory on this ...
19:30:33 <jlaska> lemme queue iSCSI up for testing in next weeks install test run
19:30:41 <jlaska> and we can discuss after those results?
19:30:56 <jlaska> sound good?
19:31:10 <adamw> sure
19:31:21 <jlaska> #agreed will revisit 560087 next week, after updated testing against iSCSI installs
19:31:32 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=576156
19:31:33 <buggbot> Bug 576156: medium, low, ---, kernel-maint, ASSIGNED, INFO: possible circular locking dependency detected - 2.6.33-1.fc13.i686 - mdadm/3174 is trying to acquire lock
19:31:42 <adamw> in general i think we can't consider error messages that don't actually associate with fatal problems as blockers...the 'possible circular locking' error is a pretty generic one and often seems to pop up but not cause any real problems
19:32:11 <Oxf13> that's a fair point.
19:32:24 <jlaska> in general yeah
19:32:30 <jlaska> but sometimes these are a bit in your face
19:32:36 <jlaska> like during boot
19:32:51 <jlaska> I don't know if I'd be comfortable shipping with one like that
19:33:02 <Oxf13> for an iscsi system, I'm OK
19:33:09 <Oxf13> if it were on every system, I wouldn't be OK
19:33:21 <jlaska> right on, that's what I meant
19:33:39 <adamw> we don't have any criterion which requires no error messages on boot. we *do* require all _services_ to start without error messages in the final criteria, but that's not quite the same
19:34:09 <adamw> we also require no abrt errors in a default boot, so if there were a kernel message which showed up for everyone which abrt picked up, that'd be a blocker
19:34:12 <jlaska> and the no error msgs on boot is specific to the default install
19:34:23 <jlaska> adamw: ah, good exercise
19:34:32 <jlaska> does ABRT grab these circular dep issues?
19:34:38 <jlaska> I'll have to poke that next time
19:34:49 <jlaska> /topic bug is another one that shows up during RAID installs
19:35:10 <jlaska> "I don't think this needs to be a blocker bug.    "
19:35:12 <jlaska> from cebbert
19:35:27 <adamw> abrt excludes some kernel messages. not sure about the circular deps ones.
19:35:28 <jlaska> with links to the upstream changes needed
19:35:57 <jlaska> #help does ABRT capture and offer reporting of kernel circular dependency problems
19:36:16 <jlaska> given that cebbert has identified the upstream patches, and this doesn't cause the RAID install to fail
19:36:31 <jlaska> anyone opposed to moving this to Target?
19:36:34 <adamw> nope
19:37:02 <jlaska> #agreed 576156 can move to F13Target, does not prevent RAID installs
19:37:02 <adamw> are you doing the change or shoudl I?
19:37:24 <jlaska> I got it
19:37:41 <jlaska> skipping a MODIFIED, and going to ..
19:37:49 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=523024
19:37:50 <buggbot> Bug 523024: medium, high, ---, jochen, ASSIGNED, Fail to Perform Example Update
19:38:33 <adamw> doesn't seem like a blocker to me.
19:38:39 <adamw> ksplice isn't an official feature or a critical package.
19:38:53 <adamw> issue doesn't seem to hit any of the criteria.
19:40:48 <jlaska> caiqian added this to the list
19:40:51 <Oxf13> yeah, =1
19:40:52 <Oxf13> er -1
19:41:40 <jlaska> #agreed 523024 - not a F13Blocker bug - ksplice not a feature or critpath, unclear how impacts existing release criteria
19:41:49 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=571573
19:41:50 <buggbot> Bug 571573: medium, low, ---, laine, POST, SELinux is preventing /sbin/ip6tables-multi access to a leaked /proc/mtrr file descriptor.
19:42:17 <jlaska> Laine has fixes posted upstream ... I gather pending review
19:43:03 <jlaska> Richard Jones added this to the list ... his explanation seems sensible to me
19:43:06 <jlaska> up libvirtd
19:43:09 <jlaska> "This is from a fresh Fedora 13 install.  It happens as soon as you start
19:43:30 <Oxf13> yeah, sounds good to me
19:43:32 <jlaska> +1 from me
19:43:51 <adamw> it's slightly borderline as the criteria are written, since we don't start libvirtd by default
19:44:00 <adamw> but i'm okay with taking it as a blocker for sure
19:44:11 <jlaska> jforbes: any concerns?
19:45:07 <jforbes> Yeah, I think blocker is good
19:45:12 <adamw> hiya ajax
19:45:32 <jlaska> #agreed 571573 - borderline criteria since libvirtd isn't enabled by default, but team agreed this was a F13Blocker
19:46:02 <jlaska> jforbes: thx
19:46:04 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=560628
19:46:05 <buggbot> Bug 560628: medium, low, ---, kernel-maint, NEW, KMS: Disturbed display with 2.6.32.x / 2.6.33.x
19:46:14 <adamw> ajax: the bug we were wondering about earlier was https://bugzilla.redhat.com/show_bug.cgi?id=560628 ; we're not sure about the impact
19:46:15 <buggbot> Bug 560628: medium, low, ---, kernel-maint, NEW, KMS: Disturbed display with 2.6.32.x / 2.6.33.x
19:46:32 <ajax> disturbed, eh.
19:46:40 <adamw> ajax: we don't have a lot of data; mamoru has the problem with an 855, we have one other person who tested an 855 in the test day and listed all tests as PASS except opengl . that's two whole data points
19:47:03 <ajax> i posted a patch for 85x upstream that probably helps with this
19:47:07 <adamw> ajax: i don't see _any_ other 8xx gen tests on the test day results, so we're a bit short on data here. can you get any idea from the data in the report how wide the impact of this would be?
19:47:22 <ajax> http://lists.freedesktop.org/archives/intel-gfx/2010-April/006605.html
19:47:34 <ajax> i have a backport pending for intel for f13 anyway, i'd pick this up in the process.
19:47:53 <ajax> i wouldn't call it a blocker since, if that patch works, it's not like 855 works anywhere atm
19:48:06 <ajax> or had worked in f12
19:48:31 <adamw> unless cschwengler is on crack it clearly works *somewhere*
19:49:25 <adamw> his smolt data does show he really really has an 855 - http://www.smolts.org/client/show/pub_2f0ca3e6-ddb7-486a-8972-5b7aadbde740
19:49:36 <adamw> so if he managed to get through all the test day tests without commenting on such an obvious bug...
19:49:38 <ajax> different memory configuration, if i had to guess
19:49:48 <ajax> fast enough memory wouldn't show it
19:49:59 <ajax> (again, if the fifo patch fixes it)
19:50:01 <Oxf13> cute
19:50:08 <jlaska> no kidding, ouch
19:50:24 <ajax> one sec...
19:50:37 <adamw> shall we leave this on the list pending more info, and try to get the reporter to test ajax's backport asap?
19:50:45 <jlaska> +1
19:51:08 <adamw> i wish we had more 8xx generation testing in general for f13. there's still quite a few of those out there...
19:51:19 <ajax> so, a while ago, i got some smolt data scraped out: http://ajax.fedorapeople.org/intel-usage-count.ods
19:51:28 <ajax> obviously that's only the people who bother to report
19:51:29 <jlaska> adamw: would this be the type of thing people would respond to a "Please test ..." request on test@?
19:51:35 <adamw> jlaska: if we have an 'old hardware graveyard' somewhere it'd be good if you could dig around for old intel systems
19:51:54 <ajax> but the ratios are pretty similar to what canonical's X people see, so.
19:52:02 <jlaska> adamw: I can ping the desktop test folks who sit near ajax
19:52:05 <adamw> jlaska: what might be better is to try and target it - find people who have the hardware and ask them to test. i can probably try and dig up people from the f11/f12 bugs filed on such systems
19:52:16 <jlaska> adamw: bold!
19:52:28 <ajax> so from that, 855 is about 1 in 15 of intel users? ish?
19:52:48 <jlaska> ajax: know if cmeadors and company have these adapters in their matrix?
19:53:16 <jlaska> okay, so let's hold this on the list for next week
19:53:30 <adamw> ajax: looks about right. it's a reasonably lengthy bar. :) and the whole 8xx generation, for which we don't have much data yet, is pretty big
19:53:39 <jlaska> I'll ping the RHEL desktop test team to see if they are able to reproduce
19:53:45 <adamw> ajax: anyway...can you give a rough eta for the kernel build with the potential fix?
19:53:52 <ajax> jlaska: the inventory system is showing me ~1 865 machine
19:53:58 <ajax> excuse me, 855
19:54:05 <jlaska> ajax: okay
19:54:07 <ajax> adamw: early next week?  tuesday if i'm good
19:54:13 <adamw> ajax: cool, thanks
19:54:17 <adamw> okay, so...
19:54:37 <adamw> #action ajax to build a kernel with the potential fix for this issue and post it in the bug
19:54:51 <adamw> #action adamw to try and find more people to test 8xx generation intel hardware on f13 in general
19:55:25 <jlaska> ajax: do you have time to lurk after this ... we have a few xorg-x11-drv* bugs upcoming (one more intel)
19:55:38 <adamw> oh, someone just added another 855 success experience to the report, that's helpful
19:55:54 <adamw> ajax: you don't need to track the meeting, we'll ping you if we need you...
19:56:02 <jlaska> #agreed leave 560628 on F13Blocker pending updated kernel results, and more test feedback from 855 chipsets
19:56:13 <jlaska> adamw: ajax: cool, that works too
19:56:20 <jlaska> anything else on this one?
19:57:02 <adamw> no, i think we've got it
19:57:38 <jlaska> ajax: thx!
19:57:43 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=572796
19:57:44 <buggbot> Bug 572796: urgent, low, ---, dcbw, NEW, Unable to establish a wireless connection
19:58:08 <jlaska> adamw: you're quite familiar with this one already
19:58:28 <adamw> yeah. it's a bit messy, as people wound up discussing two separate issues.
19:58:55 <adamw> anything from any commentator talking about rt2800 stuff you can ignore; this problem seems specific to knetworkmanager and possibly to peter's config
19:59:01 <adamw> we haven't quite triaged down the exact issue yet
19:59:07 <adamw> my feeling is it's too specific to be a blocker
19:59:11 <Oxf13> +1
20:00:10 <adamw> jlaska, what's your read?
20:00:43 <jlaska> you think this is only his setup ... not all ipw2[21]00 setups?
20:01:02 <jlaska> well, I can answer my own question ... ipw2200 confirmed working this morning
20:01:08 <adamw> have you tested it in KDE?
20:01:23 <adamw> peter says it works with cnetworkmanager (the console frontend for nm)(
20:01:34 <adamw> i'm asking in the kde chan at present if others have had problems
20:01:47 <jlaska> ah right, I haven't tried KDE
20:02:06 <jlaska> so the affected users here are KDE + ipw2200 ?
20:02:22 <adamw> we have one actual affected user - peter
20:02:32 <adamw> as i said, the others are really hitting something else entirely
20:02:45 <jlaska> okay
20:02:50 <adamw> he's using kde + ipw2200; don't know if others with the same combo are affected. it might be good for you to test that if you could, actually
20:03:25 <jlaska> #action jlaska to install KDE on ipw2200 laptop to test 572796
20:04:12 <jlaska> leave on list pending testing, or drop to target?
20:04:23 <adamw> oh, cai qian said 'same problem' but doesn't seem to have followed up any further.
20:04:26 <adamw> i think drop it for now
20:04:35 <adamw> and re-add it if we get info that it's more widespread than we thought
20:04:54 <Oxf13> might want to ask the KDE folken to really test out wireless networking across their users.
20:04:57 <jlaska> cai also lists an F14 package
20:05:05 <adamw> yeah
20:05:13 <jlaska> +1 to both, good suggestions
20:05:15 <adamw> Oxf13: i asked about that. rdieter's comments:
20:05:24 <adamw> <rdieter> adamw: it seems to work reliably for most folks yes.  this is the only case I've heard of it not working on a common case.
20:05:24 <adamw> <rdieter> stuff like vpn support is still a bit shaky
20:05:57 <jlaska> alright ... I think that gives us our #agreed
20:06:00 <adamw> ok
20:06:03 <adamw> i'll hit up the bug
20:06:50 <jlaska> #agreed 572796 will move to F13Target - not enough feedback to determine if this impacts all KDE + ipw2200 users
20:06:59 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=567978
20:07:00 <buggbot> Bug 567978: medium, high, ---, dcbw, NEW, Unable to activate network in loader with [*] Enable IPv6 support
20:08:18 <adamw> this looks like a maska bug
20:08:34 <jlaska> so Dan says that in the virt case, dnsmasq supports ipv6 for DNS, but not for DHCP
20:09:05 <jlaska> so it's just the nature of running the installing in a virt guest and accepting the default selected [*] Use IPV6
20:09:14 <jlaska> not sure if that means we should change the default or not
20:09:54 <adamw> so basically the impact is if you do an install in a vm using the default choices, it can't bring up the network?
20:10:06 <Oxf13> that seems ugly
20:10:07 <jlaska> yeah
20:10:09 <adamw> (during install? post install?)
20:10:26 <jlaska> and I could swear this affected bare metal in my cube too ... which led dcbw to think our local network was to blame
20:10:33 <Oxf13> I know ipv6 i sa default when doing network bringup in loader, is it the same in stage2?
20:10:46 <jlaska> not offered in stage#2
20:10:55 <jlaska> we still only offer ipv4 on those stage#2 dialogs
20:10:56 <adamw> dan's suggestion to make the default try ipv6 but fallback if it fails seems sane
20:10:57 <Oxf13> ok, so this is a loader only issue
20:11:11 <jlaska> Oxf13: seems to only show up in that env
20:11:15 <Oxf13> ... (why do we offer ipv6 in loader if we don't in stage 2?)
20:11:22 <adamw> ah, so this is if you're loading over the network - pxe case?
20:11:34 <jlaska> I asked that too .. it's on dcantrell's roadmap I believe
20:11:42 <Oxf13> ... for F13 ?
20:11:44 <jlaska> adamw: PXE, or boot.iso (askmethod)
20:11:54 <jlaska> Oxf13: no, F14 or beyond
20:11:59 <jlaska> Oxf13: so it's odd for now
20:12:11 <Oxf13> perhaps an "easy fix" is to not offer ipv6 or at least not offer it by default.
20:12:12 <adamw> so this affects all virt cases and may affect bare metal depending on the router capabilities
20:12:31 <adamw> yeah, i'm kinda thinking we should at least workaround this _somehow_ for final
20:12:57 <adamw> i think i'm +1 to accept this as a blocker, with a broad range of potential fixes...
20:13:30 <jlaska> there's a caveat that I might be -1 if this involves opening up /sbin/loader :)
20:13:55 <jlaska> was the fallback something dcbw needs to add to NM, or a loader change?
20:14:07 <adamw> the installer's not using nm, is it?
20:14:16 <jlaska> it uses nm now
20:14:18 <adamw> ah
20:14:47 <Oxf13> jlaska: we've got time to test loader changes
20:15:04 <Oxf13> better to do it now, than last minute when we're at RC stage and decide that this truly is a blocker.
20:15:09 <jlaska> Oxf13: famous last words! :D
20:15:27 <jlaska> no I agree this needs to be addressed somehow
20:15:34 <jlaska> so +1 from all to keep on the list
20:15:42 <jlaska> and next steps ... dcbw has the ball?
20:16:26 <adamw> i think +1 with a recognition that there's a lot of ways we can improve this and just about anything that makes it work without major changes is okay
20:16:37 <adamw> we don't need The Perfect Fix
20:17:22 <jlaska> #agreed 567978 is a valid F13Blocker - affects all virt cases and may affect bare metal depending on router configuration
20:17:45 <adamw> i'll poke the bug
20:17:48 <jlaska> adamw: thx
20:17:50 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=539471
20:17:51 <buggbot> Bug 539471: medium, medium, ---, nobody, NEW, Review Request: libserializer - JFreeReport General Serialization Framework
20:18:36 <Oxf13> wtf?
20:18:38 <jlaska> a review request as a blocker ... any objections to removing
20:18:40 <Oxf13> a review is a blocker?
20:18:46 <Oxf13> this has to be blocking something else right?
20:18:57 <jlaska> no, direct against F13Blocker
20:19:07 <Oxf13> This JFreeReport General Serialization Framework is a dependency
20:19:07 <Oxf13> of jfreereport which itself is a dependency of the reportdesigner extension of
20:19:07 <Oxf13> OpenOffice.org
20:19:10 <jlaska> added by Caolan
20:19:53 <adamw> seems pretty no-brainer to me
20:19:53 <jlaska> am I missing something, can review requests be blockers?
20:20:02 <Oxf13> if they block a feature, perhaps
20:20:08 <Oxf13> but we're past feature freeze, so...
20:20:09 <jlaska> too late for that though, right?
20:20:10 <jlaska> yeah
20:20:15 <Oxf13> I'm -1 on blocker.
20:20:27 <jlaska> -1
20:21:06 <jlaska> #agreed 539471 - not a F13Blocker, is a review request, we are past feature freeze and no criteria exist specific to package reviews
20:21:22 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=579686
20:21:23 <buggbot> Bug 579686: medium, low, ---, rstrode, NEW, Can't switch progressbar and text boot screen
20:22:24 <jlaska> interesting
20:22:38 <jlaska> don't think we have specific criteria on this issue
20:23:09 <jlaska> I know this works as expected on my bare metal tests ... so specific to virt
20:23:13 <Oxf13> yeah, can't really see how this is a blocker.
20:23:14 <adamw> this doesn't seem blockery.
20:23:20 <adamw> especially since there's a workaround.
20:23:21 <jlaska> I'd propose for F13Target (nice to have)
20:23:23 * jforbes agrees
20:23:29 <adamw> worth a common_bug note, maybe, if it doesn't get fixed.
20:23:53 <adamw> also f13target under oxf13's proposed definition of 'things we'll take a fix for that aren't blockers'.
20:24:07 <jlaska> yeah
20:24:31 <jlaska> #agreed 579686 - not a F13Blocker.  Workaround exists, move to F13Target (nice to have)
20:24:47 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=582590
20:24:48 <buggbot> Bug 582590: medium, low, ---, richard, NEW, Preupgrade starts on VT7 but it runs on VT1
20:25:28 <jlaska> this is awefully similar to ...
20:25:39 <jlaska> https://fedoraproject.org/wiki/Common_F13_bugs#black-screen-on-kickstart-install
20:26:03 <Oxf13> yeah.
20:26:34 <adamw> so, https://bugzilla.redhat.com/show_bug.cgi?id=577708
20:26:35 <buggbot> Bug 577708: high, low, ---, akozumpl, MODIFIED, Black screen during graphical kickstart install
20:26:52 <jlaska> we just need a new anaconda build to test, but that seems very similar
20:27:05 <jlaska> there's an updates.img in that bug that kparal can test
20:27:19 <jlaska> leave on the list pending feedback?
20:27:26 <adamw> add a comment pointing kparal to 577708, ask him to test the modified updates.img and close as a dupe if it works?
20:27:32 <jlaska> will do ...
20:28:33 <jlaska> #agreed 582590 - ask for testing using updates.img from 577708
20:28:45 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=572148
20:28:46 <buggbot> Bug 572148: medium, low, ---, richard, NEW, Traceback when trying to update to Fedora 13 Alpha
20:29:44 <jlaska> kparal notes this appears to be fixed with the test packages provided
20:30:02 <adamw> right, but 1.1.5 hasn't been submitted as an update yet
20:30:22 <jlaska> yup ... I can't find specifics about how this failure occurs
20:30:25 <adamw> so, we should ask hughsie to submit it?
20:30:41 <jlaska> we have multiple reports of the issue
20:30:57 <Oxf13> yeah, should ask him to submit or why it hasn't been submitted yet
20:31:00 <jlaska> adamw: yeah
20:31:06 <adamw> well he only asked kparal to test yesterday
20:31:12 <adamw> so i guess he just wanted that result before submitting
20:31:20 <adamw> oh, today, in fact :)
20:31:41 <jlaska> I'm fine leaving it here for now ...
20:31:43 <adamw> i think i'm +1 as a blocker, btw.
20:32:09 <jlaska> hughsie noted he's prioritizing the preupgrade bugs, but since he's the new maintainer could use assistance
20:32:14 <jlaska> +1
20:32:28 <jlaska> this is another one for tracking, but the fix goes into F-12
20:33:04 <jlaska> #agreed 572148 - affects preupgrade to F-13 and a valid F13Blocker
20:33:37 <jlaska> #info positive test results, needs build + update for F-12
20:33:45 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=575400
20:33:46 <buggbot> Bug 575400: medium, low, ---, richard, ASSIGNED, Preupgrade generated kickstart with an error
20:35:08 <jlaska> "preupgrade-1.1.5-0.3.fc13.noarch finally looks ok :) Fixed.    "
20:35:33 <jlaska> same situation, positive testing, looks like it needs a bodhi update now
20:35:47 <jlaska> seems straightforward ... breaks preupgrades from F-12 -> F-13
20:35:56 <jlaska> objections?
20:36:06 <adamw> nope, +1 here
20:36:56 <jlaska> #agreed 575400 - valid for F13Blocker
20:37:03 <Oxf13> +1
20:37:35 <jlaska> btw ... we can always do #undo ... I'm just trying to work through the list
20:37:50 <jlaska> #info awaiting bodhi update with new preupgrade package
20:37:56 <adamw> bug updated
20:37:58 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=571727
20:38:00 <buggbot> Bug 571727: medium, low, ---, akozumpl, ON_QA, python-meh makes the user click 'exit installer' twice
20:38:28 <jlaska> I'm all for taking this, but it's probably more for F13Target
20:38:44 <Oxf13> yeah, Target
20:38:49 <jlaska> Whenever encountering a traceback in anaconda, and filing it (scp, bugzilla, local fs) ... you are prompted 2 times for exiting
20:38:59 * jlaska updates bz
20:39:19 <adamw> yeah, target.
20:39:44 <adamw> i mean, obviously f13 won't have any installer bugs anyway, right? so you'll never notice this. ;)
20:39:58 <jlaska> :)
20:40:07 <jlaska> #agreed 571727 - move to F13Target
20:40:19 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=567119
20:40:20 <buggbot> Bug 567119: medium, low, ---, tbzatek, NEW, seahorse doesn't run
20:40:56 <jlaska> seahorse works fine here
20:40:59 <Oxf13> yeah, close this
20:41:17 <adamw> yeah, me too
20:41:17 <jlaska> needinfo? on hadess?
20:41:27 <adamw> would be a blocker if it actually was broken, but...it doesn't seem to be.
20:41:37 <jlaska> okay, close and suggest reopening if problem remains
20:41:40 <adamw> i think we can close and ask him to re-open. yeah
20:42:42 <jlaska> #agreed 567119 - seems to no longer be an issue, close bug
20:42:45 <jlaska> closed
20:42:53 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=577709
20:42:54 <buggbot> Bug 577709: high, low, ---, cdahlin, NEW, upstart: unable to shutdown or reboot after yum dist upgrade
20:44:39 <Oxf13> I'd say leave it as a blocker
20:44:53 <jlaska> seems like notting still working on this
20:45:18 <notting> um, yeah. sure!
20:45:25 <jlaska> heh
20:45:26 <adamw> does this affect preupgrade case?
20:45:37 <notting> (note: any solution will involve trading one bad consequence for a different one)
20:45:38 <notting> adamw: no
20:45:44 <adamw> if preupgrade works i would say this isn't a blocker, as we don't officially support yum upgrade.
20:45:58 <adamw> i don't think we can block on a yum upgrade problem, particularly one for which there's no non-problematic fix.
20:45:58 <jlaska> kparal didn't report this from his preupgrade testing the other day
20:46:00 <Oxf13> notting: you're already yum updating from one release to another, so....
20:46:24 <Oxf13> adamw: we still have a lot of people doing it, and we should make it easy if we can
20:46:31 <adamw> as notting said in comment #4, i think documenting as a release note or common bug is reasonable
20:46:42 <notting> Oxf13: you have a choice - either you can't reboot without -f, or your ttys don't respawn
20:46:45 <adamw> Oxf13: sure, that's not the same as it being a release blocker, though.
20:46:46 <jlaska> yum upgrading comes with reading special upgrade instructions online anyway right?
20:47:23 <adamw> definitely by the criteria we have, this isn't a blocker. yum is not listed in the upgrade methods in the release criteria, and that's intentional./
20:47:33 <jlaska> F13Target (nice to have) seems to fit here
20:48:00 <adamw> indeed. and leave it to notting's judgement what the most reasonable compromise is
20:49:59 <adamw> should we #agreed that?
20:50:06 <Oxf13> fine by me
20:50:17 <jlaska> #agreed 577790 move to F13Target, yum upgrade between releases is not a release criteria
20:50:22 <jlaska> updated bz
20:50:38 <jlaska> adamw we've reached xorg*
20:50:45 <jlaska> this is your realm :)
20:50:59 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=532308
20:51:00 <buggbot> Bug 532308: medium, low, ---, jglisse, ASSIGNED, KMS:RS480:X200M Bad 3D performance/Hangs
20:51:18 <adamw> i haven't gone through many of these yet
20:52:08 <jlaska> adamw: would you prefer tackling these after test day round-up?
20:52:30 <adamw> no, it's fine, just go through them as they come up
20:52:37 <adamw> so this is our good old friend the frickin' xpress 200m
20:53:01 <jlaska> boooh 2009
20:53:11 <adamw> i'm asking airlied if he's around
20:53:41 <adamw> if yingbo is correct, looks like we should pull the patch from the upstream kernel report mentioned in comment #21
20:54:50 <jlaska> looks like he reported against F12 Beta ... did we choose not to block F12 for this issue
20:55:22 <adamw> i don't think it was considered
20:55:32 <jlaska> doesn't look like was considered
20:55:33 <adamw> on the blockeriness, i think dodgy 3D isn't sufficiently important to block the release
20:55:40 <adamw> so i'd be -1 on this as a blocker
20:56:03 <jlaska> adamw: you've got a good mental check-list for X blocker-ness
20:56:38 <jlaska> like 2D at a minimum
20:56:46 * drago01_ thinks we shouldn't threat 3D as "nice to have" .. but well
20:56:50 <adamw> yeah, if it's only affecting 3D it'd better affect every system in the world =)
20:57:03 <jlaska> yeah, I'd agree on that
20:57:08 <adamw> drago01_: well, at this point it pretty much is de facto; we still don't have official 3D support for half the cards in the world (nvidia)
20:57:13 <Oxf13> drago01_: problem with that is we'd be waiting forever if 3d was a blocker :/
20:57:37 <adamw> anyway, it'd certainly be nice to see this fixed, but let's not make it a blocker
20:57:45 <jlaska> +1
20:58:17 <drago01_> adamw, Oxf13 : I don't really disagree here ... but longer term we should pay more attention to such bugs
20:58:24 <drago01_> anyway offtopic
20:58:38 <adamw> hi airlied, thanks for coming
20:59:01 <adamw> airlied: we just covered https://bugzilla.redhat.com/show_bug.cgi?id=532308 , decided it wasn't a blocker, but it would be nice to get the fix, which looks to be available from upstream kernel
20:59:02 <buggbot> Bug 532308: medium, low, ---, jglisse, ASSIGNED, KMS:RS480:X200M Bad 3D performance/Hangs
20:59:13 <drago01_> adamw: well we didn't have any support before .. so when 3d works on card X it should not stop working on FN+1
20:59:56 <adamw> jlaska: next bug?
20:59:57 <jlaska> #agreed 532308 can move to F13Target - nice to have 3d on this adapter, 2d not affected
21:00:14 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=522955
21:00:15 <buggbot> Bug 522955: medium, medium, ---, xgl-maint, ASSIGNED, UMS:RS480:X200M VT Switch Failure with Radeon Driver
21:00:42 <adamw> another lovely xpress 200m
21:01:04 <adamw> hasn't had a comment for a while, but cai set it as an f13blocker on march 14th
21:01:08 <adamw> so we can assume he was still seeing it then
21:01:15 <jlaska> needs testing against test day images
21:01:35 <adamw> note: airlied says he's logging but is busy repairing a washing machine so he may not reply real time
21:02:10 <adamw> I think we should ask for a re-test and leave this
21:02:23 <jlaska> +1
21:02:50 <jlaska> #agreed request retesting of 522955 and leave on F13Blocker
21:03:04 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=523914
21:03:05 <buggbot> Bug 523914: medium, high, ---, peter.hutterer, ASSIGNED, Mouse does not move in PV Xen guest under RHEL-5.4
21:03:52 <adamw> looks like this should be bumped forward to f13 from the last comment
21:04:04 <adamw> do we consider xen guests as critical? i forget
21:04:15 <airlied> drop the vt switch one, it should be fixed anyways, I'm ignoring UMS bugs in favour of fixing kms anyways
21:04:17 <adamw> oh, yeah. "The release must boot successfully as a virtual guest in a situation where the virtual host is running a supported Xen implementation "
21:04:19 <airlied> so no UMS bug should be a blocker
21:04:51 <adamw> airlied: oh yeah, forgot that was ums only
21:04:57 <adamw> airlied: i'll ask what his kms problem is currently
21:05:28 <jlaska> adamw: hmm, that criteria was specific to the infrastructure teams xen deployment
21:05:42 <jlaska> I don't imagine they are doing much runlevel 5 xen work
21:05:49 <jforbes> Eh, I don't think it should change
21:05:53 <adamw> it doesn't _say_ that, though.
21:06:11 * jforbes thinks xen guest is still an important platform for the moment...
21:06:11 <jlaska> adamw: true true
21:06:13 <adamw> admittedly 'boot successfully' is vague, but so far we've been treating it to mean 'more or less work'
21:06:30 <adamw> i'd be +1 for this as a blocker
21:06:33 <jlaska> so this was fixed at one point, but has since regressed
21:06:39 <jforbes> not to mention that EC2 is a xen environment
21:06:49 <jlaska> ah, right
21:07:04 <Oxf13> did the reporter have to go out of his way to enable UMS?
21:07:05 <jforbes> I didn't notice the regression on virt test day
21:07:11 <Oxf13> as opposed to KMS ?
21:07:23 <jlaska> jforbes: you're +1 ?
21:07:41 <jforbes> jlaska: I am +1 for it being a blocker, but unsure that it is still happening really
21:07:44 <adamw> Oxf13: for the radeon bug? yes, default is kms.
21:07:51 <adamw> Oxf13: you have to do 'nomodeset' to disable it.
21:07:59 <Oxf13> ok.
21:08:07 <Oxf13> does htis bug happen without 'nomodeset' ?
21:08:11 <adamw> jforbes: blockeriness and fixedness are separate qualities for the purpose of this meeting :)
21:08:28 <adamw> Oxf13: if I and dave recall correctly, no. he likely has another bug preventing him using kms. we're asking which one he's seeing.
21:08:34 <Oxf13> ok.
21:08:45 <Oxf13> I'm in favor of a KMS based issue being a blocker, but not a UMS
21:08:57 <jlaska> #agreed 523914 impacts F13 release criteria, remains on F13Blocker
21:09:00 <adamw> Oxf13: right, if he has an issue preventing him using kms, we're more likely to consider that the blocker.
21:09:17 <adamw> ball on 523914 is presumably with Peter to provide a fix / declare it should already be fixed?
21:09:51 <Oxf13> wouldn't the ball be in the "does hits happen with kms" court?
21:10:00 <adamw> um. you're mixing up two bugs
21:10:07 <Oxf13> oh, my bad.
21:10:12 <Oxf13> I missed the topic change
21:10:13 <adamw> =)
21:10:27 <jlaska> adamw: yeah, we need a bit more detail on the failure conditions now, otherwise it's on Peter
21:10:38 <adamw> sorry, airlied commented on the radeon bug after we'd already switched to the xen bug, so we got confused. we're on the xen bug now
21:10:55 <adamw> okay, i'll update the bug
21:11:00 <jlaska> #info Peter to provide a fix, or update the bug with latest status
21:11:04 <Oxf13> I thought the xen bug was where the UMS/KMS thing was happening, so I was even further confused
21:11:11 <jlaska> hehe
21:11:37 <jlaska> 4 bugs remaining
21:11:40 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=530692
21:11:41 <buggbot> Bug 530692: high, high, ---, ajax, ASSIGNED, No Virtual Consoles after Installation
21:12:37 <adamw> another old cai bug he's added to the blocker list
21:12:41 <jlaska> I vote for a request for updated testing (added to list on March 14, reported against F12-Beta)
21:12:45 <adamw> seems like he's just added all his bugs to blockers...
21:12:56 <adamw> yeah, we definitely need further info
21:13:06 <jlaska> adamw: can you update bz?
21:13:09 <adamw> will do
21:13:16 <jlaska> should we remove it?
21:13:21 <jlaska> or wait for more info
21:13:53 <adamw> wait for a week at least
21:14:00 <adamw> consider removing if he doesn't reply next week
21:14:06 <jlaska> #agreed not enough info on 530692 - awaiting updated test results
21:14:58 <jlaska> okay next
21:15:02 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=580423
21:15:03 <buggbot> Bug 580423: medium, low, ---, xgl-maint, NEW, Frequent crash of xserver with resizing pcmanfm
21:15:44 <adamw> interesting one
21:15:48 <adamw> ajax: looks like your domain
21:15:59 * adamw is not feeling like he wants to test this *right now* :)
21:16:15 <adamw> this would have implications for, i believe, lxde spin; i think pcmanfm is default file manager there
21:16:21 <ajax> i dig the empty backtraces.
21:16:24 <jlaska> oh, eew
21:16:56 <jlaska> I take it ABRT applet doesn't run in lxde
21:17:08 <ajax> that would be too heavyweight.
21:17:18 <ajax> (my loathing for alternative DEs poorly masked, sorry)
21:17:43 <adamw> heh
21:17:51 <ajax> gah, and on an 855.
21:17:54 <adamw> mamoru was actually testing in gnome
21:18:01 <adamw> "When resizing pcmanfm on GNOME (only tested on GNOME)"
21:18:08 <adamw> so odd the backtrace is empty
21:18:21 <ajax> i've seen a couple of those recently.
21:18:40 <ajax> i think gcc is being a shithead and optimizing the call out because it thinks that's a cool thing to do.
21:18:47 <adamw> it's kind of borderline for a blocker, though obviously something we'd like to fix
21:19:04 <ajax> yeah, stick it on the blocker list, i'll see what i can find
21:19:09 <adamw> i would like to test this myself, but again, right now is not the most opportune time =) if it's both application _and_ gfx chip specific, that's pretty tight conditions.
21:19:24 <jlaska> agreed
21:19:43 <adamw> let's say...if i test after the meeting and can't reproduce this, drop it to target?
21:19:52 <adamw> if i can, leave it as a blocker for now
21:20:04 <ajax> sure
21:20:36 <jlaska> +1
21:20:55 <jlaska> #action adamw to retest 580423
21:21:24 <jlaska> #action 580423 - pending testing, may drop to F13Target
21:21:29 <jlaska> #undo
21:21:30 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x2b03b09372d0>
21:21:34 <jlaska> #agreed 580423 - pending testing, may drop to F13Target
21:21:44 <jlaska> 2 more bugs
21:21:47 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=579756
21:21:48 <buggbot> Bug 579756: medium, low, ---, ajax, NEW, closing clutter games sometimes crashes the X server
21:22:33 <drago01_> there are upstream fixes for that one
21:22:38 * airlied guesses that is dri2 upstream hacks
21:22:48 <drago01_> airlied: yeah though the same
21:23:06 <adamw> ajax: what's your read?
21:23:41 <ajax> oh, that one.
21:23:58 <ajax> man, krh was a lot easier to coerce when he sat behind me
21:24:13 <ajax> yeah, definitely a blocker
21:24:39 <adamw> haha
21:24:51 <adamw> it's an intel driver issue? would affect all intels?
21:25:19 <ajax> no, it's a dri2 issue
21:25:28 <ajax> should affect radeon too
21:25:30 <adamw> oh so it affects...lots of things. right. feels blockery.
21:25:47 <adamw> so we just wait for it to grind through the upstream process then make sure we have the fix downstream, i guess
21:26:05 <jlaska> does that typically move quickly
21:26:21 <ajax> i expect krh will have a fix in about a week, yeah
21:26:34 <ajax> if he doesn't, well, i know the resource code pretty well too...
21:26:58 <jlaska> heh ... okay, we've got 2 weeks until the Final 'test compose'
21:27:09 <jlaska> that timing could work out well
21:27:18 <jlaska> so all +1's for blocking?
21:27:26 <adamw> yup
21:27:45 <jlaska> #agreed 579756 is a F13Blocker - awaiting upstream patch review
21:28:11 <jlaska> last one ...
21:28:13 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=577468
21:28:14 <buggbot> Bug 577468: medium, low, ---, xgl-maint, NEW, Exiting quadrapassel causes X to restart
21:28:21 * jlaska wonders if this is related to previous bug
21:28:28 <drago01_> it looks like the same to me
21:28:32 <ajax> almost certainly
21:28:44 <drago01_> quadrapassel uses clutter => glx 1.3 => hits the bug
21:28:46 <adamw> heh. yes.
21:28:48 * jlaska goes to DUP it
21:28:53 <adamw> yup
21:29:31 <jlaska> odd, duping the old bug to the new one ... no matter
21:29:35 <jlaska> which ever one is going to move fwd
21:30:34 <drago01_> the former had a more generic description
21:30:49 <jlaska> #agreed 577468 is a DUP of 579756
21:31:04 <jlaska> okay folks ... that concludes F13Blocker
21:31:30 <jlaska> I'm afraid to ask if there is anything else folks would like to cover today
21:31:51 <jlaska> if not, let's close out and we can work our action items
21:32:01 <jlaska> T-30 seconds to #endmeeting
21:32:13 <adamw> yaaaay
21:32:14 <Oxf13> OH GOD END IT NOW
21:32:23 * jlaska removes knife from ocular cavity
21:32:36 <jlaska> #endmeeting