17:02:26 <tflink> #startmeeting f17-final-blocker-review-meeting-6
17:02:26 <zodbot> Meeting started Fri May 18 17:02:26 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:33 <tflink> #meetingname f17-final-blocker-review-meeting-6
17:02:33 <zodbot> The meeting name has been set to 'f17-final-blocker-review-meeting-6'
17:02:39 <tflink> #topic roll call
17:02:48 * nirik is lurking around
17:02:52 <tflink> who's ready for some blocker review awesomeness?
17:02:56 * l0ft1369 is here
17:03:04 <tflink> l0ft1369: welcome!
17:03:08 <l0ft1369> thank you
17:05:12 <l0ft1369> sooo blockers?
17:05:46 <tflink> waiting for more people
17:05:50 <l0ft1369> oh oh ok
17:05:53 <tflink> hopefully some will show up :)
17:06:00 <tflink> right now, it's just the 2 of us
17:06:07 <l0ft1369> sorry first time... a bit over energetic I think
17:06:14 <tflink> no worries
17:06:22 <l0ft1369> it is? if I dump who it shows like 12?
17:06:48 <tflink> yeah but not everyone in the channel is here for blocker review
17:07:00 <tflink> adamw: you around?
17:07:00 * satellit_Tris55R listening
17:07:23 <l0ft1369> oh oh I get it now
17:07:41 <cpuobsessed> another round?
17:08:10 <cpuobsessed> still learning how to use irssi
17:08:11 * l0ft1369 nods
17:08:31 <tflink> cpuobsessed: yep, should be a quicker one this time
17:08:44 * tflink uses irssi as well
17:09:04 <cpuobsessed> tflink: how do i leave other rooms without disconnecting
17:09:04 <l0ft1369> only 4 blockers right?
17:09:11 * l0ft1369 uses BitchX
17:09:25 <tflink> 4 accepted blockers, 7 proposed NTH, 0 accepted blockers
17:09:44 <tflink> cpuobsessed: /part to leave channels, /window close for PM
17:09:48 <jwb> might want to look at 822981
17:09:55 <jwb> as a proposed blocker
17:10:27 <cpuobsessed> that should clean up some of the noise
17:10:31 <jwb> just got opened about 10min ago
17:12:37 <tflink> jwb: so the effect is that current binutils may result in non-bootable kernels on EFI?
17:12:42 <pjones> right
17:12:54 <pjones> or worse; they may boot and have subtle bugs that don't make any sense.
17:13:34 <tflink> crap, I was hoping for no proposed blockers today
17:13:40 <jwb> there were reports in the upstream binutils bug of syslinux being impacted as well.  not sure if that is going to matter for 32-bit live media or not
17:14:00 <cpuobsessed> not just a fedora issue?
17:14:08 <l0ft1369> that's what I was wondering
17:14:39 <tflink> well, we seem to have enough people to get started
17:14:42 <jwb> no but that doesnt matter much
17:14:44 <tflink> on with the boilerplate!
17:15:05 <tflink> #topic Introduction
17:15:19 <tflink> #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:15:43 <tflink> We'll be following the process outlined at:
17:15:44 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:15:51 <tflink> The bugs up for review today is available at:
17:15:52 <tflink> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:16:06 <tflink> The criteria for release blocking bugs can be found at:
17:16:06 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria
17:16:06 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria
17:16:07 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria
17:16:29 <tflink> any objections to starting with our lone proposed blocker?
17:16:48 <l0ft1369> 822981?
17:16:55 <tflink> #info 1 proposed blocker
17:16:55 <tflink> #info 4 accepted blockers
17:16:55 <tflink> #info 7 proposed NTH
17:17:03 <tflink> #topic (822981) binutils 2.22.52.0.1 miscompiles the kernel
17:17:03 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=822981
17:17:03 <tflink> #info Proposed Blocker, NEW
17:17:04 <buggbot> Bug 822981: unspecified, unspecified, ---, nickc, NEW, binutils 2.22.52.0.1 miscompiles the kernel
17:17:25 <tflink> jwb, pjones: how likely is it that this is going to cause problems?
17:17:31 <tflink> I assume that it affects the kernels in stable?
17:18:17 <tflink> is there anything we can do to poke at the issue in order to get a better feel for how much of a problem it is?
17:18:29 <tflink> wait, this isn't going to require a mass rebuild, is it?
17:19:02 <pjones> no, just kernel
17:19:08 <tflink> good
17:19:08 <drago01> syslinux?
17:19:25 <jwb> my understanding of the problem is fairly limited.  it causes some relocated kernels on 32-bit to crash because those are post-processed
17:19:50 <pjones> drago01: no; syslinux may be /telling/ the kernel it's relocated, but the bug is fundamentally that the kernel is built wrong
17:20:12 <drago01> pjones: ah ok
17:20:53 * tflink is reading the lkml thread
17:21:08 * l0ft1369 wonders if anyone is running a 32 bit kernel right now?
17:21:22 * tflink does on some machines
17:21:40 <l0ft1369> yes I have a virtual machine I am trying to throw together right now
17:22:32 <cpuobsessed> i'm running 32bit now
17:22:40 <jwb> i run it on a local machine here.  the kernel is clearly misbuilt, but it has been booting fine
17:22:41 <cpuobsessed> in vbox
17:22:54 <jwb> i'm guessing this is due to it being BIOS, which pjones already suggested will probably be ok
17:22:55 <pjones> tflink: if userland has an unrelocatable section, that's fine, it just gets mapped at whatever address it needs to be mapped at.
17:23:32 <pjones> tflink: when we relocate the kernel, though, we *have* to relocate all of it, because, you know, virtual memory isn't a thing.
17:24:38 <cpuobsessed> pjones, how would i cause a crash? just random chance?
17:24:51 <tflink> one would think that we'd have seen reports of problems by now since binutils-2.22.52.0.1-10 was submitted almost 2 months ago
17:25:07 <tflink> but like you said, it may be causing problems that just aren't attributed
17:25:10 <pjones> cpuobsessed: well, if we don't relocate that section and we do need to be, we're probably overwriting /something/ else with it
17:25:39 <pjones> cpuobsessed: on machines where relocating is required, we're probably calling into your firmware randomly?
17:26:01 <pjones> that is, instead of calling the functions that should have been relocated and weren't because they're marked A
17:26:42 <pjones> though that does seem weird given which symbols it is; I can't completely explain it.
17:26:43 <cpuobsessed> i see, most likely if your machine has been running for while?
17:27:42 <pjones> Oh, hrm.
17:28:06 <l0ft1369> so is this a userland only thing?
17:28:44 <pjones> wait, lemme read some more code.  I need to understand how these symbols are actually used.
17:29:01 <cpuobsessed> i think this is an NMI, has anyone reported this?
17:29:06 <tflink> this sounds like one of those bugs whose impact can only be determined after release :-/
17:29:08 <cpuobsessed> as far as Fedora goes
17:29:27 <cpuobsessed> tflink: +1
17:29:40 <pjones> tflink: maybe.
17:29:44 <tflink> is there a fix available?
17:29:51 <pjones> the more I read it, the more it seems like it's just not going to free up initcode memory.
17:30:06 <l0ft1369> Arch rolled back whatever patch intorduced it
17:30:15 <l0ft1369> but that's the only "fix" I've read about
17:31:58 <nirik> theres some 'tip' commits that fix it, but also reorg stuff and bring in new features. hurray.
17:32:25 * cpuobsessed is waiting for 3.4 kernel for his CR-48
17:32:56 * nirik suggests we move on a circle back to this when more is known?
17:33:01 <jwb> l0ft1369, upstream binutils dropped the patches that changed the section symantics
17:33:07 <jwb> it's been fixed in upstream binutils
17:33:34 <tflink> yeah, it sounds like more info is needed before making a decision
17:33:34 <l0ft1369> ok
17:33:47 <cpuobsessed> so roll back binutils before building kernels
17:33:54 <l0ft1369> ew
17:33:54 <cpuobsessed> simple
17:33:56 <cpuobsessed> ?
17:34:06 <l0ft1369> but what if you are trying to do it through yum?
17:34:06 <cpuobsessed> tflink: next!
17:34:07 <tflink> #info this bug was just filed. impact and details are not clear yet, will revisit when more info is available
17:34:22 <cpuobsessed> ack
17:34:28 <l0ft1369> yea knew that was coming
17:34:29 <tflink> cpuobsessed: I'd really rather not roll back something like binutils if we don't absolutely have to
17:35:08 <cpuobsessed> tflink: agreed, only the real real power users build their own kernels
17:35:11 <tflink> ok, on to the accepted blockers - this should be quick since we went over them yesterday
17:35:11 <jwb> we could, you know, fix it too
17:35:13 <jwb> but hey
17:35:18 <cpuobsessed> i was more thinking on the fedora hosted side of things
17:35:26 <l0ft1369> ouch
17:35:30 <tflink> jwb: fix it? That sounds like crazy talk :-D
17:35:39 <jwb> anyway, gotta run
17:36:01 <cpuobsessed> fix it, absolutely but how long would that take?
17:36:06 * tflink is kidding, of course
17:36:08 <cpuobsessed> until then
17:36:17 <tflink> anyways ...
17:36:24 <tflink> #topic (794927) PackageKit cannot import GPG keys - Fatal error: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_5ftransaction_5ferror.Code14: Invalid input passed to daemon: char '<' in text!
17:36:28 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=794927
17:36:29 <buggbot> Bug 794927: urgent, unspecified, ---, hughsient, MODIFIED, PackageKit cannot import GPG keys - Fatal error: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_5ftransaction_5ferror.Code14: Invalid input passed to daemon: char '<' in text!
17:36:31 <tflink> #info Accepted Blocker, MODIFIED
17:36:55 <cpuobsessed> i've run into that one myself
17:36:56 <tflink> not much to say here
17:37:01 <tflink> new builds are in RC2
17:37:05 <tflink> needs testing and verifivcation
17:37:23 <tflink> #info new PK builds are in RC2, this needs testing and verification so we can close it
17:37:27 <tflink> #undo
17:37:27 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2d0e1b10>
17:37:38 <tflink> #info new PK builds are in RC2, this needs testing and verification so we can determine whether or not it is fixed
17:38:10 * cpuobsessed hasn't had a chance to test Rc1
17:38:35 <tflink> #topic (821077) Firstboot window does not fit the screen after install from F17 TC4 Final KDE Live
17:38:38 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=821077
17:38:39 <buggbot> Bug 821077: unspecified, unspecified, ---, mgracik, ON_QA, Firstboot window does not fit the screen after install from F17 TC4 Final KDE Live
17:38:40 <tflink> #info Accepted Blocker, ON_QA
17:38:43 <tflink> this feels ... pointless
17:38:52 <tflink> all of the accepted blockers are in the same boat
17:39:02 <tflink> #info new PK builds are in RC2, this needs testing and verification so we can determine whether or not it is fixed
17:39:12 <tflink> #topic (822123) Graphical grub is unusable slow
17:39:12 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=822123
17:39:12 <tflink> #info Accepted Blocker, ON_QA
17:39:13 <buggbot> Bug 822123: unspecified, unspecified, ---, pjones, ON_QA, Graphical grub is unusable slow
17:39:14 <adamw> try that again
17:39:17 <adamw> or...don't
17:39:22 <tflink> #undo
17:39:22 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2d0e1910>
17:39:24 <tflink> #undo
17:39:24 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2d0e1a50>
17:39:26 <tflink> #undo
17:39:26 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2c620650>
17:39:27 <adamw> the 'new PK builds' do not fix firstboot. =)
17:39:34 <tflink> #undo
17:39:34 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x3035f7d0>
17:39:38 * l0ft1369 is lost
17:39:58 <tflink> #info the new firstboot build is in RC2, this needs testing and verification so we can determine whether or not it is fixed
17:40:10 <cpuobsessed> twiddled the notes
17:40:12 <tflink> details ...
17:40:23 <tflink> #topic (822123) Graphical grub is unusable slow
17:40:23 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=822123
17:40:23 <tflink> #info Accepted Blocker, ON_QA
17:40:24 <buggbot> Bug 822123: unspecified, unspecified, ---, pjones, ON_QA, Graphical grub is unusable slow
17:40:50 <tflink> #info new anaconda build is part of RC2 - this needs more testing and verification to determine whether or not it can be closed
17:41:16 <tflink> #topic (822495) Fedora 17 DVD build does not contain device-mapper-multipath
17:41:19 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=822495
17:41:21 <buggbot> Bug 822495: urgent, urgent, ---, kanarip, MODIFIED, Fedora 17 DVD build does not contain device-mapper-multipath
17:41:22 <tflink> #info Accepted Blocker, MODIFIED
17:41:48 <cpuobsessed> is it there in RC2?
17:41:50 <tflink> #info spin-kickstarts and comps were changed for RC2 - this needs to be tested to determine whether or not it can be fixed
17:42:19 <tflink> #info a new spin-kickstarts build will be needed before release if the changes are accepted
17:43:19 <tflink> ok, I think that's it for the accepted blockers
17:43:54 <cpuobsessed> brb
17:44:24 * tflink is going to skip any of the proposed NTH w/o associated builds
17:44:56 <tflink> #topic (821957) Missing Requires(post) on grep and coreutils
17:44:56 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=821957
17:44:57 <tflink> #info Proposed NTH, MODIFIED
17:44:58 <buggbot> Bug 821957: unspecified, unspecified, ---, tagoh, MODIFIED, Missing Requires(post) on grep and coreutils
17:45:46 <tflink> this doesn't sound very NTH-worthy
17:46:03 <cpuobsessed> what does it mean?
17:46:18 * l0ft1369 is glad someone else asked that
17:46:28 <tflink> extra error messages, I think
17:47:03 <cpuobsessed> if someone submitted this to me, i'd reject it (but then again I can't see the bz)
17:47:23 <adamw> if the errors are harmless then why the hell is it running the commands at all?
17:47:26 <pjones> since you're very likely to already have those installed by the time fontutil gets there, I think this is a "do it zero-day".
17:48:37 <adamw> the scenario cited in the upstream report is a live compose
17:48:46 <adamw> where you can never quite rely on what ordering yum's going to pick
17:48:51 <pjones> adamw: it's building a cache to improve usability
17:48:54 <adamw> i've seen this kind of thing zoom by in my yum compose logs before
17:49:07 <adamw> right. so if you happen to be building a live image and fontconfig gets installed before mkdir, you won't have the cache.
17:49:12 <adamw> not critical, but not 'harmless', i guess.
17:49:24 <adamw> unless it just does it again later.
17:49:55 <pjones> yeah, dunno.
17:50:00 <pjones> I mean, I would hope so, but...
17:50:07 <adamw> i suppose if we're going to take it that far, then what's it going to build a cache _of_ if you haven't got your fonts installed yet? ah, foo.
17:50:37 <adamw> it's late and we don't know for sure that this breaks anything...so -1.
17:51:06 <tflink> yeah, this doesn't seem to be a huge problem right now
17:51:18 <l0ft1369> what could it break?
17:51:38 <adamw> font packages all seem to run fc-cache in their own %post, but i don't see the mkdir anywhere else, immediately.
17:51:51 <adamw> l0ft1369: theoretically, you could not have a fontconfig cache, i guess. which probably makes font rendering slower or something.
17:52:19 <pjones> gotta wonder why the dir isn't owned by a package
17:52:22 <l0ft1369> adamw: so basically at worst people's terminals would be crawling instead of running through scripts?
17:52:24 <tflink> proposed #agreed - 821957 - RejectedNTH - This claims to be harmless error messages and likely would result in issues building a font cache. While unfortunate, does not seem critical and thus rejected as NTH
17:52:33 <adamw> yeah, that seems odd. why mkdir it in post instead of just owning it. oh, who knows.
17:52:39 <adamw> l0ft1369: probably not even that drastic.
17:52:41 <pjones> ... and it is!
17:52:50 <adamw> so...it's entirely redundant. well, that's dumb.
17:52:56 <pjones> eddie:~/devel/fedora/kernel$ rpm -q fontconfig -l  | grep var
17:52:56 <pjones> /var/cache/fontconfig
17:52:56 <pjones> /var/cache/fontconfig
17:52:58 <pjones> a couple of times.
17:53:07 <adamw> belt, braces _and_ suspenders.
17:53:18 <adamw> ack
17:53:20 <l0ft1369> well then I think we should advise people to enjoy the slow walk
17:53:39 <tflink> other ack/nak/patch?
17:53:41 <adamw> in fact, i'd make it less strong, tflink
17:53:51 <adamw> 'could possibly result in temporary issues when generating live images' or something
17:54:04 <adamw> since it seems pretty strongly like the cache is going to get built one way or another anyhow
17:54:15 * cpuobsessed has next to no experience building images
17:54:26 <tflink> proposed #agreed - 821957 - RejectedNTH - This claims to be harmless error messages and could possibly result in temporary issues with building a font cache. While unfortunate, does not seem critical and thus rejected as NTH
17:54:26 <l0ft1369> neither do I
17:54:39 <adamw> ack
17:54:47 <tflink> proposed #agreed - 821957 - RejectedNTH - This claims to be harmless error messages and could possibly result in temporary issues with building a font cache and slowing down font rendering. While unfortunate, does not seem critical and thus rejected as NTH
17:55:26 <l0ft1369> yes
17:55:38 <cpuobsessed> ack
17:55:42 <l0ft1369> oh right
17:55:43 <l0ft1369> ack
17:55:47 <tflink> #agreed - 821957 - RejectedNTH - This claims to be harmless error messages and could possibly result in temporary issues with building a font cache and slowing down font rendering. While unfortunate, does not seem critical and thus rejected as NTH
17:55:56 <tflink> #topic (820751) F17 gcc miscompiles lilypond
17:55:57 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=820751
17:55:57 <tflink> #info Proposed NTH, MODIFIED
17:55:58 <buggbot> Bug 820751: unspecified, unspecified, ---, jakub, MODIFIED, F17 gcc miscompiles lilypond
17:56:45 <adamw> dgilmore already pulled this in, so i guess we should +1 it. =)(
17:56:50 <cpuobsessed> is lilypond installed by default?
17:56:54 <adamw> executive decisions ftw!
17:57:02 <tflink> yeah, I was about to check that - i was pretty sure it got pulled in to TC6
17:57:09 <adamw> no, but i think the point is that if there's a problem in gcc, it should be fixed on the images
17:57:24 <cpuobsessed> i see
17:57:38 <cpuobsessed> i could test
17:58:34 <tflink> proposed #agreed - 820751 - AcceptedNTH - This could cause problems with c++ compilation with the gcc as released on DVDs
17:59:08 <adamw> ack
17:59:57 <tflink> any other ack/nak/patch?
18:00:08 <bcl> ack
18:00:22 <tflink> #agreed - 820751 - AcceptedNTH - This could cause problems with c++ compilation with the gcc as released on DVDs
18:01:15 <tflink> #topic (816554) Keyboard layout does not correspond with default layout selected during installation (F17 TC1)
18:01:18 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=816554
18:01:19 <buggbot> Bug 816554: unspecified, unspecified, ---, rstrode, NEW, Keyboard layout does not correspond with default layout selected during installation (F17 TC1)
18:01:20 <tflink> #info Proposed NTH, NEW
18:02:30 <tflink> what is going on with my scripts, isn't this accepted?
18:02:55 <adamw> doesn't have the whiteboard field
18:03:03 <adamw> and i see no note of 'acceptance' in the bug
18:03:04 <adamw> so...no?
18:03:18 <tflink> sorry, looking at the wrong bug
18:03:19 <bcl> blocks: F17-accepted
18:03:19 <l0ft1369> yea I don't see it in the wiki
18:03:24 <l0ft1369> lol
18:04:06 <drago01> oh god not again
18:04:13 * drago01 hates keyboard layout bugs
18:05:41 <drago01> anyway +1 nth (I'd even even +1 it as a blocker given the "can't login" impact)
18:06:05 <tflink> yeah, I was wondering about blocker material
18:07:15 <drago01> yeah thinking about it ... this should be a blocker
18:07:25 <tflink> adamw: do you remember how we handled these in F16?
18:07:37 <drago01> it is not obvious that the layout is US so users just can't login
18:08:28 <adamw> oh, man, i don't remember. i don't know if this has changed.
18:08:38 <drago01> "There may be times where a requirement is unmet only in a particular configuration, such as with some keyboard layouts but not others, or if a particular character is used in a username, password or passphrase. In such cases, the release team should use their judgement and refer to precedent to determine whether or not the issue should be considered to block the release."
18:08:39 <adamw> i thought we'd decided to enforce that your selected keyboard layout is used all the way through.
18:08:41 <tflink> but this is different from the F16 bug
18:08:58 <tflink> this isn't unlocking the screen, this is logging in
18:09:04 * adamw fucking hates keyboard layout bugs.
18:09:38 * l0ft1369 seconds that notion
18:10:08 * tflink is +1 blocker if this affects all non-US keyboards
18:10:45 <adamw> i think we need to talk to halfline to figure out what's going on here, if it's changed, and what the intent is. but provisionally at least +1 nth/
18:11:13 <kparal> the meeting is still in progress?
18:11:17 <drago01> yes
18:11:17 <tflink> yep
18:11:18 <adamw> why has this never shown up in testing before?
18:11:21 * kparal joins in
18:11:25 <adamw> we have a test that explicitly asks you to check keyboard layout
18:11:26 <tflink> good question
18:11:33 <adamw> and people have been claiming to have run the desktop tests all the way since alpha
18:11:38 <tflink> it was reported 2012-04-26
18:11:47 <tflink> the better question is why wasn't it flagged as NTH or blocker
18:11:48 <adamw> i'm fairly sure i tested it myself once or twice, with UK English
18:11:58 <adamw> at least for Beta
18:12:01 <drago01> the more explicit criterion that I have proposed a while ago got shoot down
18:12:11 * nirik wonders what media/version they were using there.
18:12:30 <tflink> I assume that petr was using RC1
18:12:33 <adamw> both testers are rh qa so they'll be on the test composes.
18:13:28 <nirik> ok
18:14:10 <tflink> proposed #agreed - 816554 - AcceptedNTH - This is very annoying for users with non-us keyboards, at the very least. Accetped as NTH and proposed as a blocker - will re-visit after determining the number of affected users and exactly what is going on
18:14:28 <nirik> sure, ack.
18:14:32 <kparal> ack
18:14:33 <drago01> -1
18:14:39 <tflink> drago01: patch?
18:14:49 <drago01> err
18:14:54 <drago01> didn't read the end
18:15:00 <drago01> so +1
18:15:02 <drago01> sorry
18:15:18 <drago01> but it is more then just "annoying"
18:15:22 <tflink> #agreed - 816554 - AcceptedNTH - This is very annoying for users with non-us keyboards, at the very least. Accepted as NTH and proposed as a blocker - will re-visit after determining the number of affected users and exactly what is going on
18:15:38 <tflink> drago01: like I said, "very annoying at the very least"
18:15:54 <tflink> it just seems odd that we haven't had more reports if its as bad as it sounds
18:16:07 * tflink has a hard time believing that we have only 3 users testing with non-us keyboards
18:16:20 <drago01> seems like most testers either have us keyboards or silently switch the layout after install
18:16:22 <pjones> tflink: testing might be the operative part there
18:16:57 <tflink> pjones: true but one would think that we had at least one more tester in eastern europe or asia
18:17:11 * tflink is thinking non-roman chars on keyboard
18:17:39 <tflink> #topic (822241) filesystem flushing notifications show up when ejecting read-only optical media
18:17:42 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=822241
18:17:44 <buggbot> Bug 822241: medium, unspecified, ---, tbzatek, ON_QA, filesystem flushing notifications show up when ejecting read-only optical media
18:17:45 <tflink> #info Proposed NTH, ON_QA
18:18:05 <tflink> from the bug, we have -3 and +1
18:19:00 <kparal> but we have a week more now. I don't insist on my -1 too much
18:19:11 <adamw> anyone changing votes with the extra week? it is a nice bit of cleanup.
18:19:21 <kparal> but that means we should have RC3 soon
18:19:26 <drago01> it has +3 karma
18:19:41 <tflink> proposed #agreed - 822241 - RejectedNTH - While this looks bad, it is mostly an annoyance and users are unlikely to hit this using livemedia - could easily fix this with an update.
18:19:50 <tflink> before you yell, I wanted to finish typing - can change
18:20:05 * tflink isn't strongly -1
18:20:18 <tflink> would have been nice to get this into RC2 for testing, though
18:20:25 <tflink> if we do take it
18:20:52 * adamw is finding it hard to care
18:20:55 <brunowolff> RC2 has already been annouced.
18:20:58 <adamw> so that should be ack, really.
18:21:03 <adamw> we should default to 'no'.
18:21:35 <tflink> so, ack/nak/patch?
18:21:38 <kparal> ack
18:21:53 <drago01> +1
18:21:59 <drago01> we have a 0 day update anyway
18:22:02 <brunowolff> ack
18:22:14 <tflink> drago01: I assume that's an ack instead of a +1 NTH?
18:22:20 <drago01> tflink: yes
18:22:27 <tflink> #agreed - 822241 - RejectedNTH - While this looks bad, it is mostly an annoyance and users are unlikely to hit this using livemedia - could easily fix this with an update.
18:22:37 <tflink> #topic (820748) system-config-kickstart is broken
18:22:37 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=820748
18:22:37 <tflink> #info Proposed NTH, MODIFIED
18:22:38 <buggbot> Bug 820748: high, unspecified, ---, clumens, MODIFIED, system-config-kickstart is broken
18:23:12 <tflink> -1 NTH as this can be fixed with an update
18:23:30 <drago01> do we ship it on the dvd?
18:24:13 <kparal> drago01: it seems we don't
18:24:43 <kparal> I don't see it there
18:25:00 <adamw> -1
18:25:04 <drago01> then -1
18:25:05 <kparal> therefore there's nothing to discuss
18:25:15 <kparal> -1
18:25:17 <tflink> proposed #agreed - 820748 - RejectedNTH - The affected package is not included in the DVD and thus can be easily fixed by an update
18:25:21 <brunowolff> ack
18:25:22 <kparal> ack
18:25:36 <adamw> ack
18:25:38 <tflink> #agreed - 820748 - RejectedNTH - The affected package is not included on the DVD and thus can be easily fixed by an update
18:26:22 <tflink> #topic (815413) Preupgrade from F16 to F17 Beta does not regenerate pam.d/system-auth*, causing systemd-loginctl not to know about user sessions, breaking PulseAudio
18:26:25 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=815413
18:26:27 <buggbot> Bug 815413: unspecified, unspecified, ---, systemd-maint, MODIFIED, Preupgrade from F16 to F17 Beta does not regenerate pam.d/system-auth*, causing systemd-loginctl not to know about user sessions, breaking PulseAudio
18:26:28 <tflink> #info Proposed NTH, MODIFIED
18:29:21 * tflink isn't sure about this one
18:29:27 <kparal> I don't see much into it. but my opinion is in comment 35
18:30:43 <tflink> if this only affects a few upgrades and could be fixed with an update, I'm slightly -1 NTH
18:30:58 <drago01> what means "a few"
18:31:10 <drago01> i.e do we know which ones are affected and why?
18:31:19 <adamw> really old systems, basically
18:31:21 <tflink> systems upgraded through many releases
18:31:44 <drago01> many = ?
18:31:49 <adamw> i'm not sure we're entirely convinced the fix is really going to do much, as that file is unlikely to be unchanged on any system where it'd help...
18:31:52 <adamw> i think at least back to 13.
18:31:58 <drago01> not everyone reinstalls every second release
18:33:07 <adamw> no, but given the sparsity of people reporting this bug, not a lot of people have dragged their systems along that far. and it's trivial to fix for those who have.
18:33:16 <adamw> and i don't think the update actually is sure to fix them anyhow.
18:33:37 <adamw> it only updates the stock content of that file, i'm pretty sure it's marked noreplace and will be modified on any running system...imbw though.
18:35:42 <tflink> it sounds like we're slightly -1 NTH on this
18:36:42 <kparal> no objections here
18:36:56 <adamw> i'm -1 given the minor nature of the problem, the importance of the package and the question of whether in practice it fixes anything anyhow.
18:37:59 <tflink> proposed #agreed - 815413 - RejectedNTH - The bug in question should affect few users and there are questions about whether or not the proposed fix would actually fix upgrades, anyways.
18:38:46 <kparal> ack
18:38:50 <brunowolff> ack
18:39:29 <adamw> ack
18:39:33 <tflink> #agreed - 815413 - RejectedNTH - The bug in question should affect few users and there are questions about whether or not the proposed fix would actually fix upgrades, anyways.
18:39:39 <tflink> ok, that's all of the proposed NTH
18:40:03 <tflink> we have one more proposed blocker that didn't show up becase I messed up the proposal process
18:40:14 <tflink> #topic (822430) PK is stuck after installing a single update
18:40:14 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=822430
18:40:15 <tflink> #info Proposed Blocker, NEW
18:40:16 <buggbot> Bug 822430: unspecified, unspecified, ---, hughsient, NEW, PK is stuck after installing a single update
18:40:47 <kparal> I have tried to reproduce comment 6
18:40:57 <kparal> but I didn't succeed, PK didn't get stuck
18:41:00 <tflink> I haven't hit this again, so I'm not sure it's worthy of being a blocker but I did see PK freeze on me when all updates were selected
18:41:07 <kparal> OTOH it was not a clean RC1 installation
18:41:45 <kparal> there are definitely some issues there. but they seem erratic and therefore hard to fix in a short timeframe
18:42:25 <tflink> and it also seems as if the worst-case scenario is that a reboot is required
18:42:28 <adamw> has anyone talked to hughsie?
18:42:40 <adamw> i think at the least you might have to try and repro it with pkmon running
18:42:42 <adamw> or repo with pkcon
18:43:02 <adamw> not sure there's much we can with a report of 'it froze once while running it graphically, i have no information' :)
18:43:14 <tflink> very true
18:43:23 <kparal> I don't know where to dig for more information
18:43:28 <kparal> nothing in messages
18:43:54 <kparal> pkmon doesn't output much
18:44:24 <adamw> i think you get more from pkmon if you leave it running the whole time of the operation, but yeah, hughsie might know how to get better info
18:45:26 <kparal> I don't think it currently qualifies as a blocker
18:45:40 <tflink> yeah, not unless more people start hitting it
18:45:52 <tflink> I might have done something wrong
18:45:53 <adamw> ok, -1
18:46:40 <tflink> proposed #agreed - 822430 - RejectedBlocker - This sounds like it could be a problem, but there is only 1 reporter and no debug information. For now, at least, it is not a release blocking issue.
18:46:54 <kparal> ack
18:47:03 <brunowolff> ack
18:47:22 <adamw> ack
18:47:29 <tflink> #agreed - 822430 - RejectedBlocker - This sounds like it could be a problem, but there is only 1 reporter and no debug information. For now, at least, it is not a release blocking issue.
18:47:35 <tflink> ok, I think that's everything
18:47:42 <tflink> so much for a quick meeting :-/
18:47:49 <tflink> #topic open floor
18:48:05 <tflink> anything I missed or other stuff to discuss?
18:48:25 <kparal> that bug about old kernels...
18:48:42 <kparal> 820351
18:48:49 <adamw> we can go back to the binutils bug, if we didn't make a determination on that
18:48:53 <adamw> seems pretty clearly -1 now
18:50:06 <tflink> #topic (822981) binutils 2.22.52.0.1 miscompiles the kernel
18:50:06 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=822981
18:50:06 <tflink> #info Proposed Blocker, NEW
18:50:07 <buggbot> Bug 822981: unspecified, unspecified, ---, nickc, NEW, binutils 2.22.52.0.1 miscompiles the kernel
18:50:35 <adamw> so with the new info, i'm solid -1
18:50:36 <tflink> it sounds like the impact of this is going to be much less than initially feared
18:50:49 <tflink> NTH?
18:51:09 * tflink is also -1 blocker, slightly -1 NTH unless there is a fix in the next day or so
18:51:12 <adamw> not even worth that
18:51:31 <adamw> so for anyone not following in #fedora-kernel, the new info is we can't come up with any practical case where fedora users will actually hit his
18:51:32 <adamw> this
18:52:06 <adamw> the only scenarios we could come up with are 32-bit EFI (which fedora does not support) and using kdump on a 32-bit kernel (which is somewhat esoteric and fine to fix with an update)
18:52:33 <adamw> for various reasons, 32-bit BIOS installs and all 64-bit installs don't hit this.
18:52:39 <adamw> that's why we haven't had major panic in the streets.
18:52:42 <tflink> and I imagine that almost all users who are doing kdump on kernels will be updating
18:53:26 <pjones> and again - 32-bit bios will if the machine has a very uncommon memory map
18:53:48 <adamw> oh, right. but we're not sure if there's any of those out there any more...
18:54:13 <tflink> proposed #agreed - 822981 - RejectedBlocker - The only way that a user could hit this on a configuration supported by Fedora is using kdump with a 32-bit kernel or using odd hardware. As such, it can be fixed with an update and not a blocker
18:55:10 <pjones> adamw: more likely they're not used as 32-bit often
18:55:48 <adamw> pjones: oh, i see.
18:55:55 <adamw> ack
18:56:33 <tflink> other ack/nak/patch?
18:58:01 <brunowolff> ack
18:58:23 <pjones> I acked in the bug
18:58:35 <tflink> #agreed - 822981 - RejectedBlocker - The only way that a user could hit this on a configuration supported by Fedora is using kdump with a 32-bit kernel or using odd hardware. As such, it can be fixed with an update and not a blocker
18:58:41 <tflink> close enough :)
18:58:53 <tflink> #topic (820351) It's possible not to get a kernel from the new release when doing an upgrade
18:58:56 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=820351
18:58:58 <buggbot> Bug 820351: high, unspecified, ---, anaconda-maint-list, NEW, It's possible not to get a kernel from the new release when doing an upgrade
18:58:59 <tflink> #info Accepted NTH, NEW
18:59:09 <tflink> kparal: was there anything in particular that you wanted to mention?
18:59:10 <kparal> I have just a question about this
18:59:18 <kparal> a lot of people hit this ATM
18:59:29 <kparal> but after we unfreeze stable updates, it should not happen, right?
19:00:00 <tflink> as long as F17 kernels go to stable before the F16 ones do, I imagine so
19:00:28 <adamw> it...could still happen more than it used to
19:00:36 <kparal> currently main repo is frozen, stable updates are empty and that's the reason why people get fc16 kernels
19:00:42 <adamw> but it shouldn't be _as_ much of a problem
19:00:43 <adamw> right.
19:00:47 <tflink> you're guaranteed to hit this with preupgrade, though
19:01:03 <kparal> tflink: even after f17 gold?
19:01:03 <adamw> tflink: why guaranteed? only if you have updates-testing enabled in f16, that i can think of.
19:01:19 <tflink> adamw: preupgrade only grabs from the release repo - not updates or updates-testing
19:01:22 <adamw> i did ask the kernel team if they can try and wiggle things to keep the f17 kernel ahead of f16 where possible and they said they would.
19:01:30 <adamw> tflink: not updates? well that's insanely stupid. are you _sure_?
19:01:32 <kparal> tflink: are you sure about that?
19:01:33 <tflink> unless I'm completely wrong
19:01:39 <tflink> not 100% sure, no
19:01:58 <tflink> I can test to figure it out
19:02:04 <kparal> that's something to check then
19:02:15 <adamw> the changelog sure references 'updates' a lot for something which doesn't use updates. ;)
19:02:18 <kparal> otherwise the problem would affect everyone
19:02:24 <adamw> ChangeLog:  Throttle updates in download/depsolve callbacks to avoid excess CPU use
19:02:24 <adamw> ChangeLog:  some GUI updates based on mizmo's mockups; add "Show beta" checkbox
19:02:24 <adamw> NEWS: - Try to get new packages for *all* repos, including updates (bug 473966) (Will Woods)
19:02:25 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=473966 medium, low, ---, skvidal, CLOSED CURRENTRELEASE, RfE: Preupgrade should downloading new distributation with updates
19:03:22 <tflink> that does sounds like I'm wrong
19:03:30 <adamw> though it's pretty old.
19:03:35 <kparal> the reality might be different. let's check
19:03:38 <tflink> which would be a good thing, to be honest :)
19:03:54 <kparal> hmm, how do we check?
19:04:23 <tflink> I have a couple ideas
19:04:29 <adamw> # Attempt to set up any other enabled repo on the system
19:04:30 <adamw> self.setup_new_repos(download_progressbar)
19:04:30 <adamw> # Complete repo setup
19:04:30 <adamw> self.complete_repo_setup()
19:04:33 <tflink> but it might be easiest to check the code first :)
19:04:38 <adamw> why not just test a preupgrade from f15 to f16?
19:04:42 <adamw> that should make it pretty clear.
19:05:03 <tflink> true
19:05:10 <tflink> easy enough, too
19:05:13 <adamw> anyhow
19:05:28 <adamw> the bug kinda sucks, but there's not a whole helluva lot we can do about it. except maybe the anaconda dodge jkl proposed.
19:05:49 <kparal> I just wanted to check. this answers my question
19:05:51 <adamw> or, y'know, put an epoch in the kernel and then clean up all the messy bodies left over after the kernel team commits suicide.
19:06:00 <kparal> :))
19:06:21 <tflink> adamw: somehow, that sounds less than optimal
19:07:01 <adamw> okay, so, i just installed from 17 RC1 DVD, picked 'french' as the keyboard layout, set username and password as 'azerty' - i.e. hit the qwerty keys on my US keyboard - and logged in just fine.
19:07:42 <kparal> adamw: I did the same, posted that into that bz
19:08:00 <tflink> either way, sounds like we're just about done
19:08:09 <kparal> it clearly depends on language
19:08:15 <kparal> re-testing with czech
19:08:31 <tflink> #action tflink to test F15 to F16 preupgrade to verify that preupgrade uses updates repo
19:08:51 <tflink> #topic open floor
19:08:55 <tflink> anything else?
19:08:56 <adamw> <halfline> well
19:08:56 <adamw> certain layouts come paired with us
19:09:00 <adamw> that explains a lot.
19:09:21 <kparal> there's not reason to pair czech with us
19:09:27 <kparal> we have all the ascii characters
19:10:38 <adamw> cz-us-qwertz is paired
19:10:43 <adamw> cz-lat2 isn't
19:10:48 <kparal> which channel do you discuss this on?
19:10:50 <adamw> if i'm reading /usr/share/systemd/kbd-model-map correctly
19:10:55 <adamw> #fedora-desktop on gimp
19:11:02 <kparal> ugh
19:11:35 <kparal> reproduced with cz-us-qwertz
19:11:46 <adamw> which is default?
19:11:54 <kparal> us in gdm
19:12:06 <adamw> i mean, which is the one a normal czech person would pick from the list
19:12:19 <adamw> lat2 or us-qwertz
19:12:53 <kparal> normal IT guy uses czech qwerty == lat2. layman user uses czech qwertz == cz-us-qwertz
19:13:08 <adamw> i see 'Czech' and 'Czech (qwerty)', I guess the obvious thing is to go 'Czech'...which is cz-us-qwertz?
19:13:12 <kparal> yes
19:13:17 <adamw> erf.
19:13:35 <kparal> you have no idea how we hate those guys who invented this layout in the time of typewriters
19:13:41 <adamw> heh.
19:13:46 <adamw> well, anyway, we kinda have a stalemate
19:13:47 <kparal> but it's the default everywhere now
19:13:56 <adamw> there's a lot of layouts paired with US, so this is gonna affect quite a few people
19:14:02 <adamw> but halfline is dead against changing the code quickly
19:14:05 <adamw> so we're kinda screwed. yay!
19:14:16 <adamw> when you hit this, can you at least change the layout in gdm? there's a switcher?
19:14:48 <tflink> we could always block release for another month
19:15:02 <adamw> excuse me while i join the post-epoch kernel team
19:15:13 <adamw> halfline is sticking to the line that we shipped f16 this way
19:15:25 <kparal> adamw: yes, there is a switcher. you can't switch it in "unlock locked desktop" screen though
19:15:46 <tflink> kparal: wouldn't you figure this out before you got to a locked screen, though?
19:15:56 <adamw> there's not a lot you can _do_ about it.
19:16:19 <adamw> so the impact isn't really 'can't login' but 'can't login until you figure out the problem', which still sucks but sucks less.
19:16:47 <tflink> and there's always the question of how you'd figure it out if you have only 1 machine
19:16:57 <tflink> livecd, I suppose - hoping you had one around
19:17:01 <kparal> http://imgur.com/LZxJ9
19:17:18 <kparal> you have to figure out to switch keyboard, then it's fine. you have to do it for every login
19:17:27 <adamw> well, i mean, just look at the screen.
19:17:33 <adamw> kparal: or ditch the US layout in control center, of course.
19:17:47 <adamw> we can fix it post-release with an update, halfline suggests change the code upstream then put it in updates-testing for a while
19:18:09 <adamw> i think, if we shipped f16 this way, we can probably hold our noses and pass it
19:18:22 <adamw> we need to do a quick f16 install with an affected layout and check
19:19:15 <kparal> I think it's fine, the problem exists since f15 I believe
19:19:22 <kparal> another problem is here: http://imgur.com/AUjzR
19:19:41 <kparal> the layout can be changed, but you have to click on the label, which is totally unintuitive
19:19:50 <kparal> and no matter which layout I choose, I can't unlock it
19:19:54 <kparal> weird
19:20:03 <adamw> that's the unlock screen bug that was already reported?
19:20:19 <kparal> yes, a different bz
19:20:22 <adamw> what keys are different in a czech layout? is 'qwerty' enough?
19:20:36 <kparal> qwerty is "qwertz" under czech layout
19:20:49 <adamw> i'm just trying to repro on f16
19:20:49 <kparal> y and z are swapped
19:20:57 <kparal> otherwise all the letters are same
19:21:13 <adamw> with the cz-us-qwertz layout
19:21:53 <kparal> yes
19:22:08 <adamw> kparal: "It doesn't matter if it shows 'cz' or 'en' the
19:22:08 <adamw> english layout is still active (and password is written with it)"
19:22:20 <adamw> kparal: so it seems like even if you try and use the switcher it's broken, according to pschindl
19:22:23 <adamw> that's from the bug report
19:24:44 <adamw> so if we assume that these problems have been around since f16...i'd say we make the login one not a blocker (which means it won't get fixed), and take the lock screen one as nth or even blocker since it cannot be worked around, and backport the fix
19:25:03 <kparal> adamw: the reason we hit this so infrequently is that we use "czech qwerty" layout most of the time
19:25:18 <adamw> kparal: i see. but there are several other affected languages
19:25:42 <kparal> adamw: about the locker screen - it can be worked around by using Switch User and using gdm to log back in
19:25:44 <adamw> i believe it's everything in  /usr/share/systemd/kbd-model-map where the second column is (something),us
19:25:50 <adamw> kparal: oh ew.
19:27:04 <adamw> like, a ton of indian layouts, all the arabic layouts, a few others
19:27:10 <adamw> tamil
19:28:10 * adamw goes to update the bug
19:30:44 <kparal> tflink: end of meeting?
19:31:01 <kparal> we can probably close it
19:31:03 <tflink> I was waiting for you guys
19:31:59 <tflink> #info next blocker review meeting would be 2012-05-25 @ 17:00 UTC (hopefully not needed)
19:32:09 <tflink> Thanks for coming everyone!
19:32:17 * tflink will send out minutes shortly
19:32:17 <adamw> are we making a call on the keyboard bugs?
19:32:19 <adamw> or waiting for more info?
19:32:56 <tflink> either way, it sounds rather blockery to me
19:34:00 <kparal> do you want to see more fun?
19:34:07 <kparal> try to select your keyboard layout here: http://imgur.com/1hkO1
19:34:26 <tflink> can't you cancel, though?
19:34:34 <kparal> sure, you can cancel
19:35:00 <kparal> yeah, that works, true
19:35:02 <tflink> do we have enough info to vote here?
19:35:44 <adamw> we're talking promoting https://bugzilla.redhat.com/show_bug.cgi?id=741446 to blocker at this point, right?
19:35:45 <buggbot> Bug 741446: unspecified, unspecified, ---, rstrode, NEW, Can't log in after Lock screen
19:35:48 <adamw> remember there's two separate bugs.
19:36:12 <tflink> I thought we were talking about 816554
19:36:47 <adamw> well as far as 816554 goes, i have to vote -1 blocker, since we can't plausibly fix it in any reasonable time frame, and you _can_ pick the correct layout at the login screen.
19:37:14 <adamw> but for 741446 i might be +1 blocker, as we can possibly fix it (need mclasen's advice on whether the fix is safe to backport), and the workaround is much less 'correct' (use switch user)
19:37:29 <kparal> I agree, the fix is not reasonable now for 816554
19:38:43 <kparal> 741446 is already nth, and it's nastier than the gdm one
19:39:13 <kparal> let's wait for desktop team opinion
19:39:17 <tflink> then I guess we could leave it for now
19:40:09 <adamw> mm, okay
19:40:20 <adamw> shall we #topic 816554 and vote it down so it's not blocking up the list?
19:40:55 <kparal> we can easily make it nth, but it won't get fixed anyways
19:41:08 <tflink> #topic (816554) Keyboard layout does not correspond with default layout selected during installation (F17 TC1)
19:41:11 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=816554
19:41:12 <buggbot> Bug 816554: unspecified, unspecified, ---, rstrode, NEW, Keyboard layout does not correspond with default layout selected during installation (F17 TC1)
19:41:13 <tflink> #info Proposed NTH, NEW
19:41:15 <tflink> #undo
19:41:15 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x315d9810>
19:41:21 <tflink> #info Proposed Blocker, NEW
19:42:03 <adamw> so, -1 on grounds stated above (implausibility of fix, presence of workaround, fact that f16 had this too, fact that only a subset of keyboard layouts are affected)
19:42:03 <tflink> proposed #agreed - 816554 - RejectedBlocker - While nasty, there is no feasable fix within the time left before F17 GA and there is a reasonable workaround (select correct keyboard layout from GDM menu)
19:42:08 <adamw> feasible
19:42:32 <tflink> proposed #agreed - 816554 - RejectedBlocker - While nasty, there is no feasible fix within the time left before F17 GA and there is a reasonable workaround (select correct keyboard layout from GDM menu). F16 was released with this bug and the sky hasn't fallen yet
19:42:45 <adamw> ack
19:42:56 * tflink wonders how this was released w/ F16 and hasn't been reported yet
19:43:17 <kparal> petr and josef said it had been reported several times
19:43:25 <kparal> I don't remember, can't say
19:43:28 <kparal> ack
19:43:43 <tflink> #agreed - 816554 - RejectedBlocker - While nasty, there is no feasible fix within the time left before F17 GA and there is a reasonable workaround (select correct keyboard layout from GDM menu). F16 was released with this bug and the sky hasn't fallen yet
19:44:12 <tflink> #info should be added as a commonbug
19:44:28 <adamw> i think i added that field
19:45:02 <tflink> you did, indeed
19:45:04 <adamw> yeah, i confirm the bug is in f16. just tested.
19:45:17 <adamw> and the fallback gdm in f16 doesn't even have a keyboard layout switcher :/
19:45:19 <adamw> man, we release some crap.
19:45:25 <adamw> .fire entire QA team
19:45:25 <zodbot> adamw fires entire QA team
19:45:57 <tflink> how many i18n test days have we had with this bug?
19:46:03 <tflink> oh well
19:46:18 <tflink> #topic open floor (take 3)
19:46:27 * tflink assumes that there are no other topics
19:47:50 <tflink> #endmeeting