17:00:12 <jlaska> #startmeeting F15 blocker review #3
17:00:13 <zodbot> Meeting started Fri Apr 29 17:00:12 2011 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:15 <jlaska> #meetingname F15-blocker-review
17:00:15 <zodbot> The meeting name has been set to 'f15-blocker-review'
17:00:18 <jlaska> #topic Roll Call
17:00:26 <jlaska> both adamw and tflink noted they'll be a few minutes late
17:00:31 <jlaska> anyone else here for the blocker review?
17:00:46 <jlaska> iirc, rbergeron may not be joining today as well
17:01:05 <clumens> hey hey
17:01:13 <jlaska> let's get this party started, clumens is here
17:01:33 <jlaska> dgilmore, jsmith, robatino, anyone else?
17:01:40 * robatino here
17:01:47 <jlaska> sweet, thanks for joining :)
17:01:56 * jlaska waits another minute, and I think we can get moving
17:01:58 <brunowolff> I'll keep an eye out for a while, but have to leave in just under an hour.
17:02:15 <clumens> though i am going to relocate (with laptop) to the car dealer in a few minutes.
17:02:17 <jlaska> brunowolff: oh good thanks.  Actually, I like the 'just under an hour' as a goal for meeting length :)
17:02:26 <adamw> yo
17:02:31 <jlaska> adamw: that was fast
17:02:32 <adamw> my laptop's playing up...
17:02:49 <jlaska> #topic Why are we here (this meeting, not life)?
17:02:55 <jlaska> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
17:03:04 <jlaska> and a few friendly #link reminders ...
17:03:06 <jlaska> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:03:08 <jlaska> #link https://fedoraproject.org/wiki/Fedora_15_Final_Release_Criteria
17:03:11 <jlaska> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:03:21 <jlaska> adamw: playing up ... being a bad thing?
17:03:47 <adamw> whew, got it.
17:04:14 * jlaska updating blocker wiki ... will get moving in 1 min
17:05:15 <jlaska> talk amongst yourselfs, I'll give you a topic ...
17:05:40 <jlaska> okay, updated ... let's roll
17:05:41 <adamw> how the canucks are gonna win the stanley cup?
17:05:49 <jlaska> grumble grumble
17:05:52 <dgilmore> hola
17:05:53 <clumens> why grape nuts contain neither grapes nor nuts?
17:05:59 <jlaska> dgilmore: hey there
17:06:08 <jlaska> okay, quick sweep of the approved bugs ...
17:06:26 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=695389
17:06:27 <buggbot> Bug 695389: medium, unspecified, ---, akozumpl, ON_QA, Traceback when writing a kickstart for an unused lvm-on-raid (TypeError: 'NoneType' object is not subscriptable)
17:06:30 <jlaska> #info Traceback when writing a kickstart for an unused lvm-on-raid (TypeError: 'NoneType' object is not subscriptable)
17:06:44 <jlaska> ON_QA, I just pinged Clyde for feedback on this bug
17:06:56 <jlaska> the fixed anaconda is already in stable (thanks to helpful proventesters)
17:07:02 <adamw> yay
17:07:03 <jlaska> I think we can likely close this out next week
17:07:07 <clumens> outstanding.
17:07:09 <jlaska> hopefully with confirmation from Clyde
17:07:14 <jlaska> thanks clumens for the updated build
17:07:20 * jlaska about to move on
17:07:48 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=696320
17:07:49 <buggbot> Bug 696320: unspecified, unspecified, ---, mgracik, NEW, After text-mode iSCSI install and boot, firstboot-text and getty are both running - unable to login on console
17:07:53 <jlaska> #info After text-mode iSCSI install and boot, firstboot-text and getty are both running - unable to login on console
17:08:24 <jlaska> looks like Lennart pointed out a possible problem with this issue
17:08:51 <jlaska> I think we just need to get in touch with mgracik ... if I have time, I was planning to retest with lennart's proposed change
17:09:11 <adamw> yeah
17:09:16 <jlaska> nothing else needed here ... moving on ...
17:09:17 <adamw> i remember we fixed this for the console case last release
17:09:18 <clumens> is it even expeted that firstboot run on serial installs?
17:09:21 <adamw> and lennart's explanation makes sense
17:09:33 <jlaska> clumens: expected, well not sure ... it always has
17:09:37 <jlaska> but dunno if that's expected
17:09:44 <clumens> then i guess that's a "yes"
17:09:49 <jlaska> heh
17:09:57 <dgilmore> clumens: yes it does run
17:09:58 * adamw expects the unexpected
17:10:11 <jlaska> "A whole new world ..."
17:10:20 <jlaska> anything else on this one
17:10:27 <adamw> a new fantastic point of view?
17:10:32 * adamw hangs head in shame
17:10:33 <jlaska> :))
17:10:39 <jlaska> stand tall young man!
17:10:42 <dgilmore> adamw: no chocolate for you
17:10:51 <jlaska> the timing of the TC is a little different for the Final
17:11:04 <rbergeron> no one to tell us no
17:11:05 <jlaska> it's scheduled for Monday
17:11:06 <rbergeron> or where to go
17:11:13 <jlaska> rbergeron++
17:11:14 <dgilmore> jlaska: its due next week right?
17:11:20 * rbergeron rubs her magic lamp
17:11:21 <jlaska> #link http://rbergero.fedorapeople.org/schedules/f-15/f-15-quality-tasks.html
17:11:27 <jlaska> dgilmore: you bet ... early next week (monday)
17:11:40 <adamw> rbergeron: aww, i'm not the only one
17:11:47 <dgilmore> ok
17:11:48 <jlaska> this firstboot change isn't a TC must have ...but obviously would be nice to have as many fixed in the TC as possible
17:12:01 <adamw> so we want to get things pushed over the weekend
17:12:06 * rbergeron wishes her new hair job had turned out more ariel-flaming-red
17:12:12 <jlaska> pictures please
17:12:14 <jlaska> :)
17:12:26 <adamw> i'll get you some
17:12:40 <jlaska> mgracik (firstboot) isn't online right now ... I can drop him a message post-meeting
17:12:42 * dgilmore will make sure to do a stable push on sunday
17:12:51 <jlaska> dgilmore: excellent, thank you
17:13:03 <jlaska> #action jlaska - reach out to mgracik for input on 696320
17:13:11 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=684846
17:13:12 <buggbot> Bug 684846: unspecified, unspecified, ---, tbzatek, NEW, selinux denial prevents dbus activation of gnome-keyring-daemon
17:13:15 <jlaska> #info selinux denial prevents dbus activation of gnome-keyring-daemon
17:13:23 <adamw> this is for gnome apps in kde
17:13:25 <adamw> more or less
17:13:33 <adamw> so again nothing hideous for tc
17:13:55 <jlaska> looks a bit stale
17:13:58 <adamw> debugging seems to have kinda stalled
17:14:01 <adamw> i can ping rdieter
17:14:09 <jlaska> okay, thanks adamw
17:14:27 <jlaska> #action adamw reaching out to rdieter for status of 684846
17:14:32 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=697834
17:14:33 <buggbot> Bug 697834: unspecified, unspecified, ---, rstrode, NEW, Other menu appears in default installation
17:14:36 <jlaska> #info Other menu appears in default installation
17:14:50 <adamw> this one we may want to adjust the criteria and downgrade
17:14:56 <adamw> desktop team seems to be changing their mind on it
17:15:27 <jlaska> that's certainly a valid outcome
17:15:38 <jlaska> adamw: is this taking place on desktop@ or somewhere else?
17:15:56 <jlaska> "I know that we've put this in the release criteria at some point, but I don't
17:15:59 <jlaska> think fixing it for F15 is feasible at this time; too many individual desktop
17:16:02 <jlaska> files to change."
17:16:05 <jlaska> nm
17:16:11 <adamw> mostly discussing in the bug - yeah
17:16:27 <jlaska> okay, don't think there is anything we need to resolve in this meeting
17:16:35 <adamw> the criterion was requested by desktop team in the first place, so if they want to change their minds, i don't mind, does anyone else? it's not one i'm particularly wedded to.
17:16:36 <dgilmore> ehh if they want to ignore the criteria they wrote i guess we can
17:16:36 <jlaska> seems like the right people are talking (adamw+mclasen)
17:17:07 <jlaska> dgilmore: yeah, I'd say refine/remove ... I'd definitely want that criteria removed before we demote this one
17:17:22 <dgilmore> yeah
17:17:25 <jlaska> adamw: I've got no skin in that game
17:17:38 <tflink> definately agreed on changing criteria before demoting
17:17:51 <jlaska> #info Discussing adjustments to the stated desktop menu criteria, which may lower the importance of this bug
17:17:59 <jlaska> hey tflink!
17:18:05 <jlaska> moving on ...
17:18:09 <adamw> as far as fixing it goes, mclasen and I are having a constructive discussion :P
17:18:13 <jlaska> :)
17:18:14 <adamw> so yeah, i'll look after this one either way
17:18:19 <jlaska> roger
17:18:25 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=693809
17:18:26 <buggbot> Bug 693809: unspecified, unspecified, ---, tagoh, ON_QA, Error message about missing input methods should be removed
17:18:29 <jlaska> #info Error message about missing input methods should be removed
17:18:34 <tflink> is this something that would be a 1 time thing? would we want to look at giving it a pass for just F15?
17:18:35 <jlaska> This is one of caillons babies
17:18:44 <tflink> but that would be a discussion for not here
17:18:49 <jlaska> tflink: they could ask to have the criteria reinstated for F16
17:18:58 <tflink> good point
17:19:16 <jlaska> I reached out to caillon for confirmation whether this addresses the reported issue
17:19:29 <jlaska> I'm not 100% clear on how to reproduce this, but I'd love to get extra ideas
17:19:34 <jlaska> s/ideas/feedback/
17:19:37 <tflink> isn't this one that only manifests on upgrade?
17:19:45 <jlaska> hmm, you might be right
17:19:57 <jlaska> if helpful, I can reach out on i18n/l10n lists for feedback?
17:20:07 <tflink> "Ok, I see no imsettings-gnome package installed when upgrading F14 GA to F15
17:20:10 <tflink> Beta RC2. though it gets pulled in if do yum groupupdate gnome-desktop."
17:20:18 <dgilmore> yeah its upgrades only
17:20:36 <tflink> but IIRC, callion's issue wasn't so much with the packages issue as the error message itself
17:20:40 <dgilmore> its pulled in via comps
17:20:43 <adamw> that's been changed too
17:20:44 <jlaska> so if I test an upgrade from F14->F15 .. . I should now see imsettings-gnome included?
17:21:00 <dgilmore> but thats not used on updates
17:21:06 <jlaska> right
17:21:13 <tflink> you might need some different IME or language stuff installed
17:21:47 <jlaska> #help 693809 - needs test feedback for updated imsettings to land in F15
17:22:03 <adamw> i think we can just wait for caillon's feedback
17:22:07 <jlaska> tflink: I've queued up an upgrade test now, will see what I uncover there
17:22:23 <jlaska> agreed
17:22:36 <jlaska> adamw: shall we add this to the list of updates to include in the TC1 ticket?
17:22:41 <adamw> sure
17:23:00 <adamw> and by 'we' i mean 'you'
17:23:15 <jlaska> heh, I'll grab it ... just coordinating to avoid duplicate posts
17:23:26 <jlaska> dgilmore: are those RC tickets created yet?
17:23:43 <jlaska> #action jlaska - add https://admin.fedoraproject.org/updates/imsettings-1.2.2-1.fc15 to F15-TC1 rel-eng ticket
17:23:58 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=683629
17:23:59 <buggbot> Bug 683629: low, unspecified, ---, than, NEW, KWin doesn't start up in firstboot, error message: Configuration file "/root/.kde/share/config/kdedrc" not writable
17:24:11 <jlaska> #info KWin doesn't start up in firstboot, error message: Configuration file "/root/.kde/share/config/kdedrc" not writable
17:24:46 <jlaska> the reporter indicated they didn't see this problem with the F-15-Beta live cd
17:24:46 <dgilmore> jlaska: not yet
17:25:14 <tflink> yeah, I wonder if this has been fixed indirectly
17:25:46 <jlaska> adamw: can you add this to the rdieter list?
17:26:09 <adamw> i'll ping in the ticket
17:26:13 <jlaska> thanks
17:26:16 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=682001
17:26:18 <buggbot> Bug 682001: unspecified, unspecified, ---, nphilipp, ASSIGNED, s-c-services  - all read and disabled, needs to cope with systemd
17:26:22 <jlaska> #info s-c-services - all read and disabled, needs to cope with systemd
17:26:51 <jlaska> no updates since last week, other than a status change
17:26:58 <jlaska> I'll update to note that time is running out
17:28:13 <adamw> there is always a workaround for this: don't ship s-c-s
17:28:19 <adamw> we could note that too
17:28:23 <adamw> btw, is anyone secretarying?
17:28:42 <jlaska> adamw: I'll circle back on these bugs we already discussed post meeting
17:28:50 <jlaska> we can divide and conquer for the proposed list coming next
17:28:58 <adamw> ok
17:29:01 <jlaska> okay ... ready for some proposed blockers?
17:29:07 <jlaska> huh? lemme hear if folks!
17:29:09 <adamw> well, i'll do them, i don't mind, just didn't want to tstep on any toes
17:29:11 <adamw> sure!
17:29:54 <jlaska> adamw: okay, you've got secretarying duties ... tell us if you want someone else to grab a bug
17:29:58 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=696278
17:29:59 <buggbot> Bug 696278: high, unspecified, ---, dcbw, NEW, The system network services are not compatible with this version.
17:30:04 <jlaska> #info The system network services are not compatible with this version.
17:30:38 <jlaska> let's see, adamw asked for more info on this issue last week
17:31:01 <adamw> this one is looking like a guy with a seriously messed up system, but i'm not sure why.
17:31:10 <adamw> note that he didn't have rsyslog service enabled, which just ain't right.
17:31:54 <adamw> it's a bit of a mess, to be honest. i'm not sure what to do with it.
17:31:59 <jlaska> I'm still reading, but yeah ... ugh
17:32:05 <dgilmore> adamw: yeah i think this is a case of issolated messing
17:32:06 <jlaska> is it out of line to ask them to reinstall?
17:32:11 <jlaska> I just don't know where they are starting from?
17:32:16 <adamw> yeah i was thinking the same
17:32:25 <adamw> we can ask them to grab beta, or final tc1, and reinstall, and see what happens
17:32:48 <jlaska> heck, even the last successful live nightly?
17:32:51 <jlaska> or the boot.iso I pushed out earlier
17:33:29 <jlaska> I'm sorry, it's too hard to really pinpoint any single failure that could be at fault
17:33:36 * jlaska works up a proposed ...
17:34:22 <jlaska> proposed #agreed 696278 - continue to monitor issue - Unable to pinpoint any specific failures, reporters system seems horribly broken.  Requesting reinstall and updated test results.
17:34:28 <jlaska> I think this needs some patching, but ...
17:34:30 <jlaska> ack/nak/patch
17:34:52 <jlaska> If we don't have anything more concrete the day prior to RC1, I think we have to punt on this?
17:35:13 <adamw> ack
17:35:16 <dgilmore> jlaska: agreed
17:35:17 <adamw> yep
17:35:45 <tflink> as much as I don't like the solution of 'reinstall' ... ack
17:35:59 <jlaska> yeah, me neither ... it feels lame
17:36:00 <adamw> tflink: it's more a diagnostic technique in this case
17:36:09 <jlaska> heck, maybe even just booting a live image
17:36:16 <adamw> they claim to have hit this just by installing, so...ask them to do the same thing and see if it happens again
17:36:23 <adamw> if it's not reproducible it ain't a bug. or science. :P
17:36:41 <tflink> I thought it was an upgrade
17:37:23 <jlaska> proposed #agreed 696278 - NEEDINFO? - Unable to pinpoint any specific failures, requesting retest/reinstall from reporter.
17:37:30 <jlaska> one reporter claims to have used preupgrade
17:37:42 <jlaska> while the initial report has "Since installing Fedora 15...
17:37:42 <adamw> tflink: the initial reporter says after install
17:37:59 <adamw> i'm not sure the two are even hitting the same thing, whatever it is they're hitting, but it's too difficult to tell.
17:38:07 <jlaska> I *think* the preupgrade issue should be fixed now with that other Beta issue we resolved (can't recall #)
17:38:24 <jlaska> any other votes, ideas?
17:38:27 <tflink> adamw: yeah, but I'm not sure that means clean install
17:38:36 <tflink> unless I'm missing a comment
17:39:12 <jlaska> tflink: recommendations?
17:39:29 <dgilmore> jlaska: i think we need one of 2 things.  more info on how the environment was and what they did. or them to redo it all
17:39:51 <dgilmore> and preferablly knowing more about how they actually had things configured
17:39:54 <tflink> I don't understand how all the stuff works together enough to offer anything new
17:40:25 <jlaska> it doesn't really ... I see it as adjusting our message to better communicate with the reporter
17:40:38 <jlaska> ... to attempt to further isolate the real problem
17:40:44 <adamw> yeah
17:40:50 <dgilmore> jlaska: yup
17:40:52 <jlaska> so howabout this ...
17:40:58 <jlaska> instead of just a blind "please reinstall" ...
17:41:09 <jlaska> something more in line with that dgilmore suggests
17:41:20 <adamw> okay, will tweak
17:41:21 <jlaska> help us understand how this started
17:42:00 <jlaska> comments/concerns?
17:42:08 <dgilmore> *1
17:42:10 <dgilmore> +1
17:42:22 <tflink> +1
17:42:36 <jlaska> #agreed 696278 - NEEDINFO? - Unable to pinpoint any specific failures, follow-up with reporter to further isolate failure
17:42:50 <jlaska> adamw: ping me if you need any preupgrade testing ... I've got a good setup for doing those reasonably quickly
17:43:03 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=698184
17:43:05 <buggbot> Bug 698184: high, unspecified, ---, rstrode, NEW, Enabling session saving with Gnome shell makes GUI login unusable
17:43:07 <jlaska> #info Enabling session saving with Gnome shell makes GUI login unusable
17:43:23 <adamw> we voted on this midweek, right? i was +1
17:43:29 <adamw> desktop team is working on fixing it
17:43:41 <jlaska> yeah, I've got 2 votes on this, well 3 if you count me
17:43:51 * jlaska works up proposed line ...
17:44:00 <adamw> oh hey, good timing mclasen
17:44:10 <jlaska> run away!
17:44:11 <jlaska> :0
17:44:12 <adamw> we're on the session saving bug
17:44:20 <adamw> you have a proposed patch waiting on review from vuntz, right?
17:45:07 <mclasen> I think the gnome-session patch is not really necessary to fix the problem in the bug
17:45:28 <jlaska> proposed #agreed 698184 - AcceptedBlocker - impacted by the criteria that upgraded system must meet all criteria, and gnome-session saving was considered common enough to block
17:45:36 <adamw> ack
17:45:41 <dgilmore> ack
17:45:43 <tflink> ack
17:45:58 <mclasen> adamw: I just need to actually fix the clone
17:45:58 <adamw> mclasen: as far as the criteria are concerned i think we'd be happy if it didn't hang shell
17:46:01 <brunowolff> +1
17:46:08 <mclasen> adamw: it doesn't hang the shell, actually
17:46:10 <adamw> mclasen: okay, as long as you know what needs doing i think we're fine :)
17:46:14 <mclasen> it just runs mutter without any plugin
17:46:18 <jlaska> mclasen: yeah, it doesn't even need to honor the saved session :)
17:46:20 <adamw> mclasen: well, that's the apparent effect
17:46:33 <jlaska> #agreed 698184 - AcceptedBlocker - impacted by the criteria that upgraded system must meet all criteria, and gnome-session saving was considered common enough to block
17:46:53 <adamw> mclasen: fwiw tc compose is due monday so if we want the fix in that we need it over the weekend, but we don't _really_ need it to be fixed in tc, so don't worry too much about it
17:46:56 <adamw> for rc i think you have a week or so
17:47:17 * jlaska moving on ...
17:47:32 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=696864
17:47:33 <buggbot> Bug 696864: unspecified, unspecified, ---, dchen, ON_QA, [abrt] ibus-chewing-1.3.9.2-2.fc15: Process /usr/libexec/ibus-engine-chewing was killed by signal 6 (SIGABRT)
17:47:37 <jlaska> #info [abrt] ibus-chewing-1.3.9.2-2.fc15: Process /usr/libexec/ibus-engine-chewing was killed by signal 6 (SIGABRT)
17:47:57 <jlaska> "Marking this as F15Blocker, since this bug is related to the unmet Final
17:48:00 <jlaska> Release Requirement: All elements of the default panel (or equivalent)
17:48:03 <jlaska> configuration must function correctly in common use."
17:48:06 <mclasen> adamw: I'm building it right now
17:48:11 <adamw> mclasen: awesome, thanks
17:48:19 <adamw> this is a language-dependent one so hits our wiggle clause
17:48:33 <adamw> it sounds like the input method used by most mainland chinese is broken, which is indeed bad.
17:49:00 <jlaska> good news seems to be that this is already in ON_QA
17:49:00 <adamw> i'm definitely +1 nth, probably +1 blocker.
17:49:04 <adamw> right
17:49:18 <jlaska> already confirmed on the fix too, nice
17:49:40 <jlaska> so ... what about ibus-chewing is in the default panel (or overview)
17:49:54 <tflink> it's an IME, right?
17:50:06 <tflink> input method for traditional chinese?
17:50:10 <adamw> tflink: yes.
17:50:26 <adamw> jlaska: if you install with a language that needs an ime, then indeed it is part of the default panel
17:50:34 <tflink> so it shows up on the panel for a default install if you have traditional chinese selected?
17:50:39 <adamw> yeah.
17:51:03 <jlaska> okay, then I'd vote blocker for this
17:51:11 <tflink> +1 blocker
17:51:16 <adamw> for a while we all were seeing it, btw - it was that little 'keyboard' icon that showed up next to the accessibility one for a while
17:51:23 <brunowolff> +1 blocker
17:51:25 <adamw> until it was fixed not to show up unless you were using a language that needed it
17:52:06 <adamw> the functional impact is really the worst thing, though - for chinese you _need_ an input method to type anything. if the input method is broken the system's almost unusable. so, yeah.
17:52:07 <brunowolff> I need to leave now, will look at log later.
17:52:07 <dgilmore> +1 as a blocker
17:52:16 <mclasen> just to be clear: all of this is placeholder for proper ibus/xkb integration that didn't land for 3.0
17:52:23 <jlaska> #agreed 696864 - AcceptedBlocker - Affects desktop default panel (or equivalent) criteria for all mainland chinese installs
17:52:36 <jlaska> brunowolff: as always, thank you for joining and lening your input
17:52:42 <jlaska> s/lening/lending/ too!
17:52:52 <adamw> mclasen: ah, so there'll be proper shell-side integration with ibus in 3.2 / f16?
17:53:18 <mclasen> depends on finding some domain expert to work on this; it is complicated stuff...
17:53:23 <jlaska> I bet
17:53:44 <jlaska> Anything else on this one, looks like we're all set
17:53:57 <adamw> nope, move on
17:54:01 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=692230
17:54:02 <buggbot> Bug 692230: unspecified, unspecified, ---, mchristi, ASSIGNED, /etc/init.d/iscsi check for network presence needs to be systemd aware
17:54:06 <jlaska> #info /etc/init.d/iscsi check for network presence needs to be systemd aware
17:54:17 <jlaska> I think we have the missing information we needed on this one
17:54:37 <dgilmore> im +1 to this being a blocker
17:54:43 <jlaska> the problem was the /etc/init.d/iscsi script was checking to see if NM was running by using /var/log/subsys/NetworkManager
17:54:48 <jlaska> which is no longer used in the systemd world
17:54:59 <jlaska> there was an initial fix, and an improved one expected shortly
17:55:11 <adamw> yup, +1 too
17:55:22 <adamw> seems to hit the iscsi criterion pretty clearly.
17:55:26 <jlaska> impact ... any installs with a non-root network volume (iSCSI) don't mount the volume on boot
17:55:32 <jlaska> yeah
17:55:34 <jlaska> +1 blocker from me
17:55:39 <tflink> +1
17:55:39 <jsmith> +1 from me
17:56:22 <jlaska> #agreed 692230 - AcceptedBlocker - Impacts non-root network (_netdev) partitions failing to mount on boot (e.g. iSCSI)
17:56:37 <jlaska> hey jsmith :)
17:56:39 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=699896
17:56:40 <buggbot> Bug 699896: unspecified, unspecified, ---, michel+fdr, ON_QA, AVX code generation is broken in LLVM 2.8
17:56:51 <jsmith> jlaska: I'm sneaky like that :-)
17:56:57 <tflink> unless I'm missing something, -1 blocker, -1 nth
17:57:14 <tflink> and I am missing something
17:57:14 <jsmith> Not sure which criteria this is supposed to match, so -1 blocker
17:57:16 * jlaska reads
17:57:25 <jlaska> ajax around?
17:57:28 <tflink> this isn't the compiler, part of LLVM is used in mesa?
17:57:52 <jsmith> Ah, mesa...
17:57:55 <adamw> "it makes the Mesa software renderer explode when used on
17:57:55 <adamw> Sandybridge CPUs.
17:57:55 <adamw> "
17:57:59 * jsmith always forgets that it uses LLVM
17:58:11 <tflink> yeah, I read this as a "broken compiler" at first
17:58:17 <adamw> i think what this means is 'no graphics for you'.
17:58:30 <tflink> if you're using sandybridge, anyways
17:58:35 <jlaska> we have any sense for how many folks this would impact
17:58:43 <jsmith> More and more, over time
17:58:44 <dgilmore> im +1 blocker
17:58:46 <tflink> I wonder if this is related to some of the sandybridge intel graphics driver issues
17:58:47 <jlaska> or how common sandybridge is?
17:58:53 * jsmith withdraws his -1
17:59:02 <adamw> i'd like to check with ajax though
17:59:04 <dgilmore> jlaska: its intels latest and greatest
17:59:07 <adamw> jlaska: sandy bridge is intel's current gen
17:59:07 * tflink withdraws -1 too
17:59:10 <jsmith> jlaska: Most of the new Intel machines have a Sandy Bridge proc
17:59:12 <dgilmore> so it will be more and more common
17:59:18 <jlaska> do we have criteria that mesa must work?
17:59:27 <adamw> well i'd like to check with ajax on the exact impact
17:59:28 <tflink> there have already been issues around sandybridge in #fedora-qa
17:59:30 <dgilmore> jlaska: gnome shell needs it
17:59:31 <jlaska> adamw: okay
17:59:35 <tflink> not sure if they were mesa, though
18:00:05 <jlaska> adamw: did you want to invite him here, or come back to this later/post-meeting?
18:00:06 <adamw> i just pinged ajax
18:00:10 <jsmith> -ENEEDMOREINFO
18:00:10 <jlaska> k
18:00:12 <adamw> give him a minute or two
18:00:13 <jsmith> adamw: As did I :-)
18:00:32 <adamw> i _suspect_ the impact of this would be 'you boot the system, Shell tries to start up, explodes' but we should make sure...
18:00:32 <dgilmore> i guess we dont have enough to know if users will just go to fall bacr they will just up desktops
18:00:37 <dgilmore> gahh
18:00:47 <dgilmore> adamw: right
18:00:56 <dgilmore> and sewed
18:01:00 <tflink> but if this is mesa, you can't use shell with mesa, right?
18:01:06 <dgilmore> or is it going to go to fallbak mode
18:01:13 <jlaska> greetings ajax!
18:01:14 <adamw> tflink: mesa isn't just software rendering...
18:01:24 <adamw> ajax: heya - we just wanted to know the exact impact of https://bugzilla.redhat.com/show_bug.cgi?id=699896
18:01:24 <tflink> adamw: OK, didn't know that
18:01:25 <buggbot> Bug 699896: unspecified, unspecified, ---, michel+fdr, ON_QA, AVX code generation is broken in LLVM 2.8
18:01:33 <dgilmore> ajax: how screwed will users be
18:01:53 <dgilmore> will it go to fall back mode? or just give a messed up screen?
18:02:00 <ajax> what?
18:02:17 <ajax> oh.  i see what you're asking.
18:02:18 <adamw> well we're not clearly on exactly what's affected and what the result of the bug is
18:02:35 <ajax> avx is an instruction set extension in sandybridge cpus
18:02:58 <adamw> are you going to hit this with any sandy bridge system, even using the intel driver with hardware acceleration? or is it only if you're on software rendering for some reason? or what?
18:03:10 <ajax> we use llvm for code generation in several paths
18:03:23 <ajax> one is the whole of the software 3d renderer
18:03:37 <ajax> one is vertex shaders on hardware that doesn't have it
18:03:57 <ajax> if you hit any of these paths, whatever has the dri driver loaded will exit()
18:04:07 <ajax> (on an avx chip)
18:04:11 <dgilmore> ok
18:04:19 <ajax> that could be gnome-shell, or it could be your X server
18:04:20 <adamw> so...this is going to hit systems with sandy bridge CPUs and unsupported graphics cards, or graphics hardware that's missing shaders?
18:04:26 <dgilmore> i think i stick with my +1 to it being a blocker
18:04:46 <jsmith> Sounds like a lot of potential to cause disruption, then?
18:04:51 <adamw> given the impact i may be only +1 nth on this, but it's a bit academic if there's a fix in already, so let's not waste too much time
18:04:54 * jlaska wants to see the criteria impacted before voting
18:05:02 <ajax> it's pretty nasty, yeah.
18:05:19 <dgilmore> jlaska: that the desktop starts and runs
18:05:26 <ajax> the place i found it was on a nouveau nvc0 system (which is kinda supported, but we can't ship the firmware yet, so you get software 3d)
18:05:27 <adamw> ajax: would shell be running on affected systems? i mean, it doesn't work with software rendering, does it work on any hardware that's going to be using software fallback for shaders?
18:05:54 <jlaska> so this isn't just causing fallback mode, this is shell *and* fallback failing entirely
18:05:59 <adamw> i'm just not sure there's a path here which is actually going to cause shell to crash on anything but a really weird setup, i mean, afaics, anything that could get hit by this bug is probably going to be running fallback mode
18:06:16 <jlaska> yeah, that's where I'm going too
18:06:34 <adamw> this is only going to crash 3D-using stuff, right? so if you were in fallback mode the desktop wouldn't fall over?
18:06:43 <dgilmore> at the least i say +1 as nth
18:06:48 <ajax> not until you ran a GL app anyway
18:06:59 <ajax> cheese counts as a gl app, now.
18:07:03 <adamw> hum
18:07:05 <adamw> fun
18:07:08 <jlaska> curses!
18:07:16 <adamw> let's just pick one or the other, approve it, and move on
18:07:17 <ajax> anyway, it's built and i've tested it.
18:07:19 <adamw> the fix is going to get in either way
18:07:21 <jsmith> Definitely a NTH, and I'm leaning towards blocker as well
18:07:26 <adamw> so...i will +1 whatever someone wants to propose =)
18:07:32 <jlaska> I'm going with NTH for the notes
18:07:34 <jsmith> Proposal: Blocker
18:07:37 <adamw> +1!
18:07:43 <adamw> ajax: thanks for the info
18:07:46 <ajax> np
18:08:06 <dgilmore> +1
18:08:30 <jlaska> #agreed 699896 - AcceptedBlocker - tested fix available in bodhi
18:08:32 <tflink> I'm definately +1 nth on this one and leaning towards +1 blocker since I remember seeing several people having issues with sandybridge and the intel drivers
18:08:40 <tflink> and late :)
18:08:49 <jlaska> tflink: nah, I'm just impatient! :D
18:08:58 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=699905
18:09:00 <buggbot> Bug 699905: unspecified, unspecified, ---, ajax, NEW, Mesa rebuild for fixed LLVM 2.8
18:09:03 <jlaska> #info Mesa rebuild for fixed LLVM 2.8
18:09:07 <jlaska> So is this just more of the same?
18:09:15 <tflink> if the last one was a blocker, would this one be, too?
18:09:24 <tflink> added as blocker to make sure that it made it past freeze?
18:09:37 <dgilmore> +1 as its needed to go with above
18:09:42 <jlaska> yeah, it was cloned from the previous issue
18:09:49 <ajax> yeah.  mesa has a funny build system that has to construct a private dso copy of llvm at build time from the static libs
18:10:08 <adamw> ok
18:10:09 <adamw> so +1
18:10:17 <tflink> +1
18:10:18 <ajax> so if i fix a bug in llvm, i have to rebuild mesa too
18:10:28 <jlaska> #agreed 699896 - AcceptedBlocker - mesa rebuild required to address previously accepted blocker 699896
18:10:30 <ajax> (this'll be fixed soon, but it's how it is right now)
18:10:34 <dgilmore> ajax: lucky you
18:10:43 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=700276
18:10:44 <buggbot> Bug 700276: high, unspecified, ---, pbrobinson, MODIFIED, Enabling session saving with Gnome shell makes GUI login unusable
18:10:53 <jlaska> #info Enabling session saving with Gnome shell makes GUI login unusable
18:10:57 <dgilmore> didnt we do this already
18:11:00 <jlaska> This is the issue robatino discovered
18:11:03 <tflink> different bug
18:11:10 <adamw> it was cloned
18:11:10 <tflink> bug number, anyways
18:11:11 <adamw> i dunno why
18:11:16 <jlaska> yeah, I'm not clear on the clone
18:11:19 <robatino> different component?
18:11:22 <jlaska> but mclasen is here if we need guidance
18:11:41 <adamw> ah, this one has the later discussion, heh
18:11:41 <jlaska> robatino: ooh, good news with the latest comment ... new update coming
18:11:45 <mclasen> the gnome-session bug should probably just be closed
18:11:47 <adamw> i did ask why it was cloned, but no-one answer
18:11:48 <adamw> ed
18:11:53 <dgilmore> if the previous bug was a blocker then this should be also
18:11:55 <mclasen> I really should have moved it instead of cloning
18:12:04 <adamw> okay, i'll close that as a dupe of this
18:12:08 <adamw> and we already +1ed it, so move on?
18:12:09 <mclasen> because it is a mutter issue, not a gnome-session issue
18:12:12 <jlaska> So close 698184 as a DUP of 700276 ?
18:12:21 <mclasen> I just wasn't sure initially, and there was another ptach for gnome-session...
18:12:35 <mclasen> lets wait until 700276 is confirmed fixed, maybe
18:12:37 <mclasen> but yeah
18:13:02 <adamw> well we're not closing 700276
18:13:09 <jlaska> proposed #agreed 700276 - AcceptedBlocker - if updated package resolves issue, DUP 698184 against this bug
18:13:14 <adamw> just marking 698194 as a dupe of it so we don't have two bugs for the same thing...
18:13:41 <adamw> we don't really need one bug per component, we need one bug per issue
18:13:52 <jlaska> yeah, can we just DUP it now?
18:13:55 <dgilmore> yup
18:14:02 <mclasen> sure
18:14:14 <jlaska> proposed #agreed 700276 - AcceptedBlocker - addresses previously accepted gnome-session saving issue
18:14:22 <tflink> ack
18:14:25 <dgilmore> how many more bugs do we have?
18:14:25 <adamw> ack
18:14:34 <jlaska> proposed #agreed 698184 - CLOSED DUPLICATE of 700276
18:14:42 <tflink> 1 more blocker, 5 proposed NTH
18:14:45 <dgilmore> i have to leave for physio in 45 mins
18:14:51 <jlaska> dgilmore: 1 more on the proposed blockers, and ... waht tflink said
18:14:57 <dgilmore> :)
18:15:06 <jlaska> #agreed 700276 - AcceptedBlocker - addresses previously accepted gnome-session saving issue
18:15:09 <jlaska> #agreed 698184 - CLOSED DUPLICATE of 700276
18:15:18 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=679579
18:15:19 <buggbot> Bug 679579: medium, unspecified, ---, jglisse, ASSIGNED, [R2XX] GNOME Shell graphics corruption
18:15:23 <mclasen> and 700276 is back in MODIFIED, fwiw
18:15:29 <adamw> comment #39 neatly captures this
18:15:40 <jlaska> mclasen: sweet, thank you ... robatino and I will test that shortly
18:16:04 <adamw> we've been told r100 and r200 just aren't going to work for shell, but they don't fail the test for shell support, so at present they try to run shell and you get a bad result
18:16:21 <adamw> what we need here is for the shell support test to have a blacklist so it can go to fallback mode for r100/r200
18:16:22 <mclasen> adamw: owen has a blacklist patch for gnome-session-is-accelerated
18:16:33 <mclasen> I'm trying to track down if that already landed in f15 or not
18:16:35 <adamw> mclasen: cool, can you ask him to note it in this bug?
18:16:58 <adamw> i'm +1 blocker on this bug as long as that's understood to mean 'r100 and r200 should fall back', not 'r100 and r200 should work with shell'
18:17:15 <adamw> well, more properly, either of the two is an acceptable fix, but the first is what we'll get ;)
18:17:28 <jlaska> adamw: and this basically impacts any desktop criteria for folks with those adapters?
18:17:28 <tflink> +1 on what adamw said
18:17:34 <adamw> r100/r200 are the first two generations of Radeon chips, btw - anything up to the Radeon 9500, it's quite a bit of hardware
18:17:37 <jlaska> sine it doesn't properly do accel, or use fallback as intended?
18:17:41 <jlaska> s/sine/since/
18:17:47 * jlaska needs new fingers or a new keyboard
18:17:48 <adamw> jlaska: yes, because they'll wind up with a pretty useless shell rather than fallback mode
18:18:06 <jlaska> <dumb_question>r100 and r200 is fairly common?
18:18:17 <adamw> jlaska: it's old, but common at the time
18:18:25 <adamw> this is ATI hardware of 2000-2002 vintage roughly
18:18:33 <dgilmore> i still have boxes with radeon
18:18:33 <adamw> quite a lot of them are still around having been transferred into newer systems
18:18:40 <dgilmore> 7000 cards
18:18:51 <adamw> radeon 8500 and i think 9200 would be common examples affected by this
18:18:54 <jlaska> #link http://www.smolts.org/reports/view_devices?device=r200&search=Submit+Query
18:19:00 <tflink> I still have one, but I gave up using it a long time ago due to problems with linux
18:19:09 <adamw> it'd be quite hard to construct a good smolts query as the adapters could identify as a lot of things
18:19:10 <tflink> at least 1
18:19:23 <jlaska> adamw: oh right, yes
18:19:36 <adamw> r100 and r200 are the general names for these generations of chips
18:19:56 <adamw> each chip would have its own codename (say rv230) and would have been marketed under yet another name, like Radeon 8500 or Radeon 7000 or whatever
18:20:12 <jlaska> proposed #agreed 679579 - AcceptedBlocker - impacts desktop criteria for making for an unusable desktop for users with r100 or r200 series graphics
18:20:16 <adamw> ack
18:20:35 <jlaska> proposed #agreed 679579 - AcceptedBlocker - impacts desktop criteria making for an unusable desktop for users with r100 or r200 series graphics
18:20:37 <tflink> ack, with the conditions adamw mentioned before
18:21:08 <jlaska> going once ... twice ...
18:21:21 <jlaska> #agreed 679579 - AcceptedBlocker - impacts desktop criteria making for an unusable desktop for users with r100 or r200 series graphics
18:21:35 <jlaska> okay gang, let's walk through the proposed NTH's ...
18:21:50 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=699786
18:21:51 <buggbot> Bug 699786: medium, unspecified, ---, dcbw, NEW, VPN connections broken in the compat interface
18:21:53 <clumens> guess i'd better start paying attention again
18:21:53 <jlaska> #info VPN connections broken in the compat interface
18:22:01 <jlaska> clumens: you're next buster!
18:22:43 <adamw> so, as described, this means - no VPNs with knetworkmanager
18:22:43 <jsmith> Is there a criterion for VPN connections?
18:22:44 <jlaska> I don't think we'd consider anything VPN as a NTH
18:22:53 <adamw> jsmith: NTH doesn't have criteria =)
18:23:01 <jlaska> adamw: waah, we have _loose_ criteria :)
18:23:02 <clumens> OH NOES
18:23:13 <clumens> loosest criteria in town
18:23:14 <adamw> jlaska: well, i can see a situation where you couldn't get online with the live image inside a corporation or something, but yeah, it doesn't worry me hugely
18:23:22 <adamw> in most cases you should be able to install an update to fix this
18:23:22 <jlaska> bugs which constitute infringements of the desktop-related Fedora_Release_Criteria as applied to non-default desktops
18:23:25 <jlaska> bugs which result in a system being unable to reach a graphical environment
18:23:28 <jlaska> significant installer bugs which do not meet the criteria to be blocker bugs
18:23:34 <adamw> jlaska: KDE is a supported desktop, so that doesn't come into play here
18:23:45 <adamw> jlaska: if this hit a criterion it'd be a blocker. it doesn't, though.
18:24:07 <jsmith> +1 to NTH, -1 to blocker in my book
18:24:11 <jlaska> ditto
18:24:13 <tflink> didn't we accept the enterprise WPA bug as NTH?
18:24:32 <adamw> tflink: yeah, i'd say that's probably a more common case than requiring a VPN to get any network connectivity.
18:24:49 <adamw> remember, the main test for NTH is 'do we really need to fix this bug in shipped images'
18:24:55 <jlaska> right
18:24:59 <adamw> if we can fix it well with an update, it's quite hard for it to be NTH
18:24:59 <jlaska> is this needed to pull down updates?
18:25:06 <tflink> yeah, and a livecd connecting to VPN would most likely be a custom job
18:25:29 <adamw> so unless you could often get into a situation where you need a VPN to pull down updates...i'm probably -1 on this
18:25:55 <jlaska> let's ask that in the bz too
18:26:09 <tflink> I can think of situations where it would be a bit of a pain without VPN but I can't really come up with one that would keep you from updating
18:26:26 <adamw> well i think we can vote for now and they can re-propose if they don't like our vote...
18:26:30 <jlaska> proposed #agreed 699786 - RejectedNTH - doesn't appear to impact ability to download and install updates
18:26:33 <jlaska> ack/nak/patch
18:26:35 * adamw votes -1 nth -1 blocker
18:26:36 <adamw> ack
18:26:39 <tflink> ack
18:26:49 <dgilmore> tflink: only one i know of is places that use vpn for wireless security
18:27:00 <dgilmore> i know the uni i went to does something like that
18:27:07 <tflink> dgilmore: yeah, thats what I was thinking too, but you could get wired
18:27:17 <tflink> at least in the situations I've seen
18:27:19 <dgilmore> you cant get anywhere on the wireless network until you vpn
18:27:28 <dgilmore> tflink: true
18:27:40 <tflink> my school is pretty much like that, too
18:27:51 <jlaska> if that turns out to be more common, I'd recommend patching the criteria to include VPN?
18:28:07 <dgilmore> they also make you use a socks or proxy server to do the bandwidth accounting
18:28:45 <adamw> i've got "If you believe there are significant cases where it would be difficult or impossible to pull down updates without VPN connectivity, please re-propose with examples - thanks!" in the text for my comment
18:28:50 <adamw> if that makes people happy :)
18:28:52 <jlaska> thx ... was going to ask you ...
18:28:58 <tflink> works for me
18:29:04 <adamw> okay
18:29:05 <adamw> move on?
18:29:23 <jlaska> #agreed 699786 - RejectedNTH - doesn't appear to impact ability to download and install updates.  Will reconsider if VPN turns out to be required for downloading package updates
18:29:29 <jsmith> adamw: +1 :-)
18:29:31 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=696943
18:29:33 <buggbot> Bug 696943: medium, unspecified, ---, akozumpl, POST, logs got by virtio are different from the originals on guest
18:29:37 <jlaska> #info logs got by virtio are different from the originals on guest
18:29:47 <jlaska> NTH criteria - can't be fixed in an update, it's installer
18:30:15 <jlaska> and in terms of need, this is something hongqing has been exploring w/ ales and he's hoping to use this for monitoring virt installs in some automation
18:30:35 <adamw> the fix is described as low-risk, so +1
18:30:53 <clumens> yeah, seems good to me.
18:30:54 <jlaska> +1 from me, obviously
18:31:04 <mclasen> https://admin.fedoraproject.org/updates/gnome-session-3.0.1-2.fc15 is the update with the r100/r200 blacklist
18:31:08 <tflink> +1
18:31:16 <jsmith> +1
18:31:21 <jlaska> #agreed 696943 - AcceptedNTH - low-risk allows for improved virtio logging during installation
18:31:30 <adamw> mclasen: cool, thanks
18:31:36 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=699923
18:31:37 <buggbot> Bug 699923: low, unspecified, ---, bcl, NEW, livecd doesn't have /var/log/dmesg
18:31:45 <clumens> i'm all for this one too
18:31:48 <clumens> e-z patch
18:32:06 <adamw> so this is to make sure proper logs show up in automated reports from livecd installer problems?
18:32:08 <jlaska> "This would be nice to have so that we don't need to request that users add
18:32:11 <adamw> sounds good, simple fix, +1
18:32:12 <jlaska> /var/log/messages to bugs manually."
18:32:16 <jlaska> +1 NTH
18:32:19 <jsmith> +1 to NTH
18:32:21 <tflink> +1 NTH
18:32:26 <clumens> adamw: yep
18:32:38 <dgilmore> +1 nth
18:32:48 <jlaska> #agreed 699923 - AcceptedNTH - ensure consistent log locations for bug reports from livecd environment
18:32:55 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=700085
18:32:56 <buggbot> Bug 700085: unspecified, unspecified, ---, akozumpl, POST, iSCSI login dialog allows unselecting all devices and continuing - unable to login to any iSCSI devices after
18:32:59 <jlaska> #info iSCSI login dialog allows unselecting all devices and continuing - unable to login to any iSCSI devices after
18:33:10 <jlaska> this was a minor UI nit that I requested
18:33:28 <jsmith> +1 NTH
18:33:30 <jlaska> if you aren't paying attention, you can prevent adding any iSCSI volumes during install
18:33:42 <jlaska> clumens can speak to the patch risk
18:33:52 <clumens> looked good to me
18:34:06 <adamw> since we're early and have time to fix any explosions, sure, +1
18:34:24 <jlaska> I'll test this in an updates.img before TC1
18:34:27 <tflink> +1
18:34:34 <clumens> if there are bugs, it shouldn't hit anything outside of iscsi
18:34:47 <jlaska> #action jlaska - test 700085 using an updates.img prior to Final TC1
18:35:20 <jlaska> #agreed 700085 - AcceptedNTH - low risk installer iSCSI user-interface change
18:35:26 <adamw> one more!
18:35:27 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=694897
18:35:28 <buggbot> Bug 694897: unspecified, unspecified, ---, cwickert, ASSIGNED, Icons missing in desktop menu
18:35:32 <jlaska> #info Icons missing in desktop menu
18:35:38 <tflink> this one had an issue in the whiteboard, fixed
18:35:51 <adamw> oh, i screwed this up
18:35:53 <adamw> so we're good, whee
18:36:03 <jlaska> oh, already accepted?
18:36:10 <adamw> yeah
18:36:11 <jsmith> Appears to be
18:36:14 <jlaska> #info Already AcceptedNTH ... no need to revisit
18:36:18 <adamw> we marked it as AcceptedBlocker not AcceptedNTH
18:36:23 <tflink> yep, but it had acceptedblocker in the whiteboard, so the script picked it up
18:36:32 <jlaska> Ladies and gentlemen ... superb job, we are done with the list for today
18:36:37 <jlaska> #topic Open Discussion
18:36:38 <jsmith> w00t!
18:36:40 * tflink is slower than adamw, aparrantly. needs to type less
18:36:53 <adamw> yay
18:36:57 <jsmith> Again, I can't thank you folks enough for taking the time to work through the list each week
18:37:00 <jsmith> Kudos to each of you!
18:37:03 <jlaska> tflink: he's got the fastest phallenges in the west
18:37:05 <adamw> you're damn right you can't
18:37:06 <adamw> SEND BEER
18:37:11 <jlaska> HAHA!
18:37:22 <jlaska> you can tell it's the end of the meeting from the tone
18:37:25 <tflink> wow
18:37:28 <jsmith> adamw: Be careful what you wish for!
18:37:30 <adamw> =)
18:37:46 <jlaska> okay, any additional business folks would like to raise?
18:37:51 <jlaska> or, bidness, if you will?
18:37:51 * jsmith has nothing else
18:37:56 <adamw> alright, i did all the secretary-ing from the point where i raised it - the first few bugs need doing
18:37:57 <dgilmore> adamw: no beer for you
18:37:59 * adamw has nothing else
18:38:02 <adamw> dgilmore: awww.
18:38:03 <jlaska> adamw: I'm on it
18:38:37 * adamw outta here
18:38:41 <jlaska> have a great time @ LinuxFEST northwest, to any who are attending!
18:38:43 <dgilmore> adamw: i think we can get you an espresso drip though
18:38:45 <adamw> if anyone's gonna be at lfnw i'll see 'em there
18:38:56 <jlaska> thanks everyone, I'll send minutes to your favorite lists
18:38:59 * dgilmore wont be there
18:39:07 * jlaska will #endmeeting in 30 seconds
18:39:25 <dgilmore> jl	gracious
18:39:38 <jlaska> #endmeeting