15:59:54 <poelcat> #startmeeting Fedora 14 Blocker Bug Review https://bugzilla.redhat.com/showdependencytree.cgi?id=538277&hide_resolved=1
15:59:54 <zodbot> Meeting started Fri Oct  8 15:59:54 2010 UTC.  The chair is poelcat. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:03 <poelcat> #topic roll call
16:00:10 <poelcat> who is here today/
16:00:11 <poelcat> ?
16:00:32 * jlaska waves
16:00:35 <adamw> yo yo yo
16:00:42 * mcepl would add before you start note about https://bugzilla.redhat.com/show_bug.cgi?id=639146#c3 ... that's proabbly not a blocker, right?
16:00:43 <buggbot> Bug 639146: medium, low, ---, ajax, NEW, Blank display (backlight on) after KMS initialization
16:00:45 * j_dulaney is hungry, but here for a bit
16:01:28 <poelcat> hi jlaska adamw mcepl j_dulaney
16:01:30 <adamw> mcepl: judgment call, depends how many systems are affected
16:01:38 <adamw> mcepl: the fact that it's a regression is certainly bad
16:01:52 <poelcat> while we are waiting for others
16:01:59 <adamw> mcepl: and we seem to have at least three affected Dell models
16:02:22 <poelcat> do we want to try and set a time limit for each bug.. and if we aren't able to resolve set it aside and loop back on at the end of the meeting?
16:02:37 * bcl is here
16:02:40 <j_dulaney> Probably a good idea
16:02:55 <j_dulaney> bcl:  good day
16:03:10 * adamw is not a fan of time limits
16:03:19 <jlaska> I'm a fan of them when we've been on a bug for 10 minutes
16:03:20 <adamw> problem being it's just about impossible to force people to stop discussing something
16:03:33 <adamw> witness fesco meetings where people go on talking way past the time limits
16:03:36 <jlaska> howabout this ...
16:03:42 <j_dulaney> of course, I'll be leaving shortly, so I won't see the end, anyway
16:03:55 <jlaska> instead of forcing action after a time limit ... let's start by just collecting data on bugs which take too damn long to discuss
16:04:00 <mcepl> adamw: yes, but periodic nagging may help
16:04:15 <adamw> jlaska: ok
16:04:23 <jlaska> I'd be interested in trends here
16:04:27 <adamw> though we can easily do that retrospectively
16:04:29 <adamw> from the logs
16:04:34 <jlaska> incomplete triage, no activity, unclear criteria etc...
16:04:36 <poelcat> adamw: i'm looking for a way to not spend the rest of our day here :)
16:04:38 <jlaska> yeah
16:04:43 <jlaska> poelcat: see above
16:04:50 * mcepl probably won't be for long ... it's late here and family will come upon me soon, I am afraid
16:04:54 <adamw> poelcat: i know, and it's a good goal, but sometimes good goals aren't achievable :)
16:05:08 * poelcat puts tape over mouth
16:05:14 <poelcat> :)
16:05:24 * j_dulaney superglues it in place
16:05:27 <jlaska> poelcat: can we try this ...
16:05:27 <poelcat> my mouth that is
16:05:43 <jlaska> poelcat: when we hit a long bug ... add it to a list of bugs that took *too* long
16:06:05 <poelcat> okay
16:06:07 <jlaska> let's use meetbot or something (#action long-bug-review -1234 took too long to discuss)
16:06:19 <jlaska> I'd like to use #idea, but it doesn't show up niely in the meetbot output
16:06:25 <j_dulaney> Which can then be discussed in-list
16:06:35 <poelcat> #chair jlaska adamw j_dulaney mcepl
16:06:35 <zodbot> Current chairs: adamw j_dulaney jlaska mcepl poelcat
16:06:37 <jlaska> using #action, it at least won't be hidden in the irc minutes
16:07:06 <poelcat> who is going to be secretary to update comments?
16:07:16 <poelcat> or maybe we can trade off w/ leading
16:07:22 <jlaska> we know I'm not the fastest, but I'm happy to grab some as we go
16:07:23 <poelcat> i'll do first hour and then we can change
16:07:28 <poelcat> okay enough admin :)
16:07:30 * adamw will secretize
16:07:34 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528022
16:07:35 <buggbot> Bug 528022: medium, low, ---, ajax, ASSIGNED, setroubleshoot:      SELinux is preventing /usr/sbin/vbetool "mmap_zero" access on &lt;Unknown&gt;.
16:07:42 <poelcat> adamw: thanks
16:07:49 <adamw> i was gonna say, since mcepl's going to leave soon, we could start with his bug
16:07:55 <adamw> and the other X one i nominated
16:07:57 <poelcat> adamw: do it
16:08:06 <poelcat> go ahead and drive
16:08:09 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=639146
16:08:10 <buggbot> Bug 639146: medium, low, ---, ajax, NEW, Blank display (backlight on) after KMS initialization
16:08:34 <adamw> so yeah, mcepl just proposed this one for discussion...given that we have reports from three different Dell models so far and it's a regression vs F13, I'm certainly worried
16:08:48 <adamw> per the criteria, X-don't-work issues are a judgment call based on the breadth of the impact
16:09:07 <jlaska> I think I just saw this when testing the acceptance images
16:09:14 <jlaska> but I haven't triaged it enough yet
16:09:17 <adamw> Dell?
16:09:26 <j_dulaney> Giving the number of Dells out there
16:09:30 <jlaska> no, Intel SDV
16:09:41 <j_dulaney> Worse
16:09:47 <adamw> the Dell E6xxx series is a pretty popular line
16:09:50 * jlaska checks adapter
16:10:20 * adamw has a similar bug on his Vaio Z, FWIW, but likely not the same - that's https://bugs.freedesktop.org/show_bug.cgi?id=29141
16:10:21 <buggbot> Bug 29141: major, high, ---, jbarnes, NEW, [Arrandale switchable] PCH eDP panel mode setting failure at boot
16:11:26 <jlaska> so it's an X issue, the question for us is how many systems are affected by this?
16:11:29 * mcepl cries when he sees word "Arrandale"
16:11:35 <adamw> anyway, for now I'd probably vote to take this as a blocker, given the popularity of the systems involved
16:11:44 <j_dulaney> I concur
16:11:51 <Oxf13> hey I'm here.
16:11:54 <jlaska> Oxf13: welcome
16:12:00 <j_dulaney> Whatup
16:12:38 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=639146 accept as blocker
16:12:39 <buggbot> Bug 639146: medium, low, ---, ajax, NEW, Blank display (backlight on) after KMS initialization
16:12:41 * adamw tries to pull stats out of smolt quick but it's not co-operating
16:12:42 <adamw> +1
16:12:43 <poelcat> ack/nak/patch?
16:12:51 <j_dulaney> +1
16:12:59 <jlaska> +1
16:13:22 * mcepl is not sure whether he is expected to vote but if yes than +1
16:13:30 <poelcat> anyone here can vote! :)
16:13:34 <adamw> ok, we have 128 e6510s in smolt, 537 e6500s, 21 e4310s
16:13:35 <poelcat> what are the next actions for this bug?
16:13:41 <adamw> so yeah, clearly significant
16:13:55 * poelcat forgot to add that to the #action
16:13:56 <adamw> we need the detailed logs mcepl asked for
16:14:01 <adamw> then it's on ajax
16:14:16 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=639146 accept as blocker; waiting for logs mcepl requested
16:14:17 <buggbot> Bug 639146: medium, low, ---, ajax, NEW, Blank display (backlight on) after KMS initialization
16:14:18 <jlaska> I can provide detailed logs for my intel gfx failure, but not sure if same problem
16:14:36 <mcepl> jlaska: file a separate bug and mention that it looks like this one
16:14:41 <adamw> concur
16:14:44 <j_dulaney> Indeed
16:14:46 <poelcat> back to the list or are their otther bugs from people that have to leave?
16:14:47 <jlaska> mcepl: k
16:14:59 <j_dulaney> The wireless DHCP issue
16:15:03 <j_dulaney> Checking number
16:15:17 <jlaska> rvykydal_ added it to the list already
16:15:21 <adamw> yeah there's one other X issue i wanted to get before mcepl leaves
16:15:27 <jlaska> so it will come up for discussion
16:15:32 <poelcat> 640766 ?
16:15:42 <j_dulaney> @bug 640766
16:15:43 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=640766 medium, low, ---, linville, NEW, [b43] b43 wlan0 fails DHCP requests
16:15:54 <j_dulaney> Ah, yes
16:15:59 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=640766
16:16:00 <buggbot> Bug 640766: medium, low, ---, linville, NEW, [b43] b43 wlan0 fails DHCP requests
16:16:16 <j_dulaney> I'm having the same problem on my laptop
16:16:17 <adamw> ...okay after this one then =)
16:16:55 <j_dulaney> How widespread is it?
16:17:23 * jlaska thought stickster had a b43 too
16:17:25 <poelcat> shall we summon linville?
16:17:33 <jlaska> so that's the question ... how widespread, and feedback from linville
16:17:36 * adamw shoots bugzilla in the head
16:17:44 <jlaska> poelcat: sure, we can try here, or follow-up afterwards
16:17:54 <jlaska> adamw: it's a hydra
16:17:58 <j_dulaney> Well, I must go in five
16:18:12 <j_dulaney> But, it does seem to be a lovely pain
16:18:41 <jlaska> something to consider here ... traffic is working, but it's performance is degraded?
16:18:56 <jlaska> is it degraded such that installing an update would be unreasonable
16:19:04 <j_dulaney> I do agree with it seemingly a kernel issue; I tried a known to work version of Network Manager and had the same issue
16:19:11 <j_dulaney> Indeed
16:19:21 <j_dulaney> Down to one or two bits per second
16:20:07 <poelcat> do we have enough info right now to call it a blocker?
16:20:34 <j_dulaney> Unknown, but if it hurts old hardware like mine and new, it could be a problem
16:20:40 <jlaska> I don't know how common of an adapter is, that's what is missing for me
16:20:52 <adamw> it's very common
16:21:03 <adamw> but the use of the b43 driver with it is not so common
16:21:14 <jlaska> is it the default?
16:21:16 <adamw> yes
16:21:18 <adamw> but it's complicated =)
16:21:25 <j_dulaney> If it does degrade wireless to the point where updates to fix are not practical...
16:21:29 <adamw> b43 always used to need you to cut firmware out of the windows driver before it would work at all
16:21:35 <jlaska> ah
16:21:38 <j_dulaney> Indeed
16:21:46 <adamw> since f13 (i think), we've had the open firmware available by default
16:21:51 <adamw> which makes it work ootb with a few cards
16:21:59 <j_dulaney> But, it worked with F13 for me
16:22:06 <j_dulaney> On the same box
16:22:08 <adamw> but many still need firmware cut out of windows driver to work
16:22:10 <adamw> j_dulaney: ok
16:22:17 <j_dulaney> Well, I must be off
16:22:30 <jlaska> j_dulaney: sign up on the cc of that bug ... sounds like you might be a good candidate to test a potential fix :)
16:22:30 <adamw> in practice, it's probably easier to use the wl driver from fusion than set up b43, if b43 with the open firmware doesn't work for you
16:22:33 <j_dulaney> I'll try to develop more data this weekend
16:22:37 <j_dulaney> Indeed
16:22:41 <adamw> from experience in the forums, i know a lot of people actually wind up using wl
16:22:42 <j_dulaney> jlaska
16:22:44 <jlaska> adamw: ugh, not a good recommended workaround
16:22:47 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=640766 set as accepted blocker; ping maintainer: John Linville for his input; ack/nak/patch?
16:22:48 <buggbot> Bug 640766: medium, low, ---, linville, NEW, [b43] b43 wlan0 fails DHCP requests
16:22:49 <adamw> so in practical terms i'd vote -1 on this being a blocker
16:23:19 <jlaska> let's leave on the list, until next week.  I'd like to hear linville's thoughts too
16:23:44 <jlaska> adamw: having a common_bug reference directing folks to install packages from rpmfusion seems like a bad idea
16:23:49 <mcepl> I abstain, no clue about b43 anymore (thanks God!)
16:23:53 * j_dulaney is on CC list
16:23:57 <jlaska> j_dulaney: thx
16:24:00 <j_dulaney> Good day, y'all
16:24:06 <jlaska> j_dulaney: thanks for joining, cya
16:24:13 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=640766 leave as blocker for now; ping maintainer: John Linville for his input; ack/nak/patch?
16:24:15 <buggbot> Bug 640766: medium, low, ---, linville, NEW, [b43] b43 wlan0 fails DHCP requests
16:24:22 <jlaska> ack
16:24:23 <adamw> jlaska: yeah, we have to hedge around it a bit; i'm just saying that in practice most people have fairly low expectations of b43...
16:24:33 <adamw> ack, with a view to making it nth in the end
16:24:35 <jlaska> adamw: okay
16:24:59 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=640766 leave as blocker for now; ping maintainer: John Linville for his input; may ultimately make a NTH (nice to have)
16:25:00 <buggbot> Bug 640766: medium, low, ---, linville, NEW, [b43] b43 wlan0 fails DHCP requests
16:25:03 <poelcat> next bug?
16:25:11 <jlaska> yes please!
16:25:19 <poelcat> what is it?
16:25:37 <jlaska> adamw had another X issue for mcepl
16:25:54 <poelcat> okay, just let me know when the side queue is empty so I can start back on thelist
16:25:59 * mcepl would like after that talk about bloody xulrunner-python bug
16:26:14 <adamw> yup, X bug is
16:26:21 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=636326
16:26:23 <buggbot> Bug 636326: high, low, ---, bskeggs, MODIFIED, After kernel update, screen goes blank during boot
16:26:37 <adamw> there's already a fix for this one in the latest f14 kernels, but nothing past -28 has been submitted as an update yet
16:26:56 <adamw> so it seemed a good idea to have it on the blocker list just to make sure there's something on there making sure we get a newer kernel build for final
16:27:10 <adamw> i'd like to get kernel team to put in whatever fixes they have left and have their proposed 'final'
16:27:13 <adamw> kernel for tc1...
16:27:28 <poelcat> adamw: can you do that befor Tuesday?
16:27:49 <mcepl> adamw: shouldn't it be NEEDINFO(reporter)?
16:27:50 <poelcat> TC is two days early for final
16:28:16 <mcepl> otherwise, +1 with having the latest and greatest kernel
16:28:24 <adamw> mcepl: we already have fix confirmed by Steven
16:28:54 <mcepl> well, you asked reporter ("Michael, did you test the kernel Ben linked to above?")
16:29:00 <mcepl> anyway, just a nit
16:29:04 <jlaska> +1 to fixing this ... it hits my nouveau system as well
16:29:18 <jlaska> well, 2 systems that I have w/ nouveau (small data sample mind you)
16:29:22 <poelcat> is htis a NTH or Blocker?
16:29:45 <mcepl> poelcat: I understood adamw he wants to make it a blocker as a way to get latest kernel
16:30:13 <adamw> i think it makes blocker on its own merits as a regression in a post-beta kernel
16:30:30 <adamw> but yeah, having it there also has the side effect of making sure we get a later kernel than -28 for final
16:31:57 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=636326 set as accepted blocker--anything else?
16:31:58 <buggbot> Bug 636326: high, low, ---, bskeggs, MODIFIED, After kernel update, screen goes blank during boot
16:32:07 * jlaska phone
16:32:21 <adamw> poelcat: no, just that
16:32:22 <adamw> +1
16:32:24 <mcepl> +1
16:32:33 <jlaska> +1
16:32:34 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=636326 set as accepted blocker
16:32:35 <buggbot> Bug 636326: high, low, ---, bskeggs, MODIFIED, After kernel update, screen goes blank during boot
16:32:39 <poelcat> next bug!
16:32:55 <mcepl> #topic https://bugzilla.redhat.com/show_bug.cgi?id=639985
16:32:56 <buggbot> Bug 639985: medium, low, ---, dmalcolm, NEW, Firefox crashes with xulrunner-python installed
16:33:36 <mcepl> I would just suggest to make it NTH ... there isn't reproducer, affects only Sugar,
16:34:19 <poelcat> definitely not a blocker thehn
16:34:22 <mcepl> (I haven't talk with neither Martin nor Christopher about it, just my personal opinion)
16:34:29 <Oxf13> I agree.
16:34:42 <poelcat> mcepl: so you are proposing as NTH?
16:34:42 <adamw> yeah, +1 nth
16:34:47 <mcepl> yes
16:34:53 <mcepl> or whatever is non-blocker
16:34:59 <adamw> (technically speaking it affects the desktop validation testing for sugar spin which is grounds for NTH status)
16:35:27 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=639985 accept as NTH because affects the desktop validation testing for sugar spin
16:35:29 <buggbot> Bug 639985: medium, low, ---, dmalcolm, NEW, Firefox crashes with xulrunner-python installed
16:35:31 <poelcat> ack/nak/patch?
16:35:39 <mcepl> I don't want to denigrate Sugar, but this bug could take some time before we understand what's going on
16:35:51 <jlaska> and rationale for NTH is desktop criteria for non-default desktop ENV, right?
16:35:58 <Oxf13> ack
16:36:02 * jlaska making sure he understands and can spread the gospel of NTH
16:36:19 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=639985 accept as NTH because affects the desktop validation testing for sugar spin
16:36:21 <buggbot> Bug 639985: medium, low, ---, dmalcolm, NEW, Firefox crashes with xulrunner-python installed
16:36:23 <poelcat> next bug!
16:36:27 <jlaska> go go go!
16:36:39 <mcepl> I have nothing left
16:36:42 <mcepl> adamw: ???
16:36:59 <adamw> nothing more that needs to go first
16:37:11 <poelcat> back to the list
16:37:25 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528022
16:37:26 <buggbot> Bug 528022: medium, low, ---, ajax, ASSIGNED, setroubleshoot:      SELinux is preventing /usr/sbin/vbetool "mmap_zero" access on &lt;Unknown&gt;.
16:37:40 <Oxf13> this again
16:38:20 <adamw> no more info since last week :/
16:38:28 <ajax> how about we do for f14 what we did for rhel6
16:38:31 <ajax> to wit:
16:38:51 <ajax> don't ship vbetool by default, and suspend is only officially supported on kms drivers
16:38:59 <ajax> and if you install vbetool and suspend works, hey, good for you
16:39:25 * jlaska notes dwalsh is around if we need him
16:39:39 <ajax> it's not his problem, it's mine
16:39:42 <jlaska> okay
16:39:57 <ajax> but the problem, fundamentally, is that vbetool is an unreliable hack
16:40:11 <ajax> we can fix this and vbetool still won't _work_ half the time
16:40:17 <adamw> ajax: can you answer my q from last week? is there any way to have vbetool do what it does without triggering selinux?
16:40:23 <ajax> yes, there is.
16:40:32 <adamw> how much beer does it need to get done? :P
16:40:47 <ajax> it's kind of a lot of work, and all you're fixing is suspend on broken hardware.
16:40:58 <adamw> well hey, that's more or less the story of our lives.
16:40:59 <ajax> (video that isn't intel, nv, or ati)
16:41:10 <ajax> qemu doesn't need it
16:41:11 <adamw> (unless we're waiting for people to not want to suspend and only ever buy working hardware.)
16:41:16 * jlaska wonders how much X test week testing will be invalidated if we now remove vbetool from default
16:41:30 <adamw> jlaska: just about none
16:41:37 <ajax> jlaska: how many testers did you have that were not using one of those four environments?
16:41:38 <Oxf13> video that isn't intel, nv, or ati is a vanishingly small set
16:41:49 <adamw> as x test week covers kms drivers only and as ajax puts it, they don't need / use vbetool
16:41:57 <adamw> so basically we have three choices here
16:41:59 <jlaska> ah, got it ... thanks
16:42:17 <adamw> leave the current situation: advantage, it may make suspend work on some non-mainstream graphics chips, disadvantage, everyone gets this annoying selinux alert
16:42:38 <adamw> drop vbetool by default: advantage, no-one sees the annoying selinux alert, disadvantage, suspend probably breaks on some non-mainstream chips
16:42:42 <mcepl> ajax: ping? discussing vbetool bug
16:42:55 <adamw> fix vbetool: advantage, does 'the right thing for everybody', disadvantage, involves lots of work which makes ajax cry
16:43:01 <ajax> mcepl: scroll up, yo
16:43:26 * adamw would like to vote for option 3 but recognizes that's because he wouldn't be the one fixing vbetool =)
16:43:28 <jlaska> option#1 is a criteria issue
16:43:32 <Oxf13> I'm with ajax here, go with option 2
16:43:35 <adamw> of the other two, i can probably live with either but would vote #2
16:43:39 <jlaska> options#2 and option#3 I would leave for ajax discretion
16:43:59 <adamw> and we can throw in a release note or commonbug saying to install vbetool if you've got a crazy adapter and need to suspend
16:44:03 <jlaska> but we may want to update release notes with option#2 ?
16:44:07 <jlaska> adamw: good call :)
16:44:14 <ajax> yeah, it's doc-worthy
16:44:48 <jlaska> do we need to discuss/present this resolution anywhere else?
16:44:56 <adamw> so, let's drop vbetool, and if ajax is feeling particularly saintly and fixes the other blocker then has time to fix vbetool too we can always stick it back in
16:45:13 <ajax> like i said, this is how el6 is going out
16:45:17 <jlaska> okay
16:45:25 <ajax> no one seems to have noticed there, but then, el6 people have hardware made this decade
16:45:37 <adamw> feh, we should be better than that crappy ancient product from some proprietary software company :P
16:46:02 <jlaska> proposed #action 528022 accepted as a release blocker - next steps involved dropping vbetool from default, and updating release notes
16:46:08 <adamw> so propose #agreed: we accept this as a blocker, recommended fix is to drop vbetool from comps / wherever it is, ajax to implement ?
16:46:10 <ajax> give me a second and i'll chop off vbetool from pm-utils
16:46:24 <adamw> +1 to both
16:46:25 <ajax> shouldn't be pulled in from anywhere else iirc
16:46:31 <jlaska> adamw: Oxf13 do we need a comps bug and a release note bug to track those changes?
16:46:38 <adamw> apparently it's a dep not comps
16:46:43 <jlaska> okay
16:46:51 <adamw> but for release notes yeah i think we're at the point where we'd need a bug
16:46:54 <jlaska> oh I see ... pm-utils dep
16:46:57 <adamw> if it can't make release notes we'll have to commonbugs it
16:47:02 <jlaska> I'll action the release note bug
16:47:20 <jlaska> #action jlaska file new bug against release notes to document expected vbetool changes for 528022
16:47:34 <jlaska> #action ajax update pm-utils to remove vbetool dependency to address 528022
16:47:48 <jlaska> adamw: +1 to your recommendation ... chair it when ready
16:47:55 <jlaska> "lock it in Regis!"
16:48:04 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=620635
16:48:05 <buggbot> Bug 620635: medium, low, ---, xjakub, ASSIGNED, antlr3 needs to be rebuilt against python 2.7 in F14 and devel
16:48:30 <jlaska> poelcat: one sec .. we didn't #action yet
16:48:43 <poelcat> oh, sorry, thought you did
16:48:43 * mcepl doesn't manage to read fast enough ... you are talking too fast, but yes totally agree with ajax; chop vbetool, it's long overdue
16:48:44 <jlaska> err, #agreed
16:48:50 <adamw> it's fine, we #actioned
16:48:57 <adamw> let's carry on
16:48:57 <jlaska> okay ... keep on truckin'
16:49:06 <adamw> is antlr3 on the media?
16:49:08 <poelcat> oh, i mixed up the two today :)
16:49:09 <adamw> if not, i think this becomes nth
16:49:13 <jlaska> ajax: thanks for the guidance :)
16:50:07 <ajax> np
16:51:18 <Oxf13> adamw: it's on the DVD
16:51:31 <adamw> ok, so this is obviously a blocker as it's a repoclosure issue, right?
16:51:35 <Oxf13> well, at least antlr3-java is
16:52:00 <jlaska> adamw: no
16:52:02 <Oxf13> that comes from the antlr3 srpm
16:52:09 <jlaska> adamw: err, sorry ... yes because it's media
16:52:32 <adamw> so, clearly a blocker, we have a proposed action in the bug: "I suggest removing the python runtime from the package because you have to
16:52:32 <adamw> download non-packaged version anyway to be able to use antlr3 on Fedora."
16:53:02 <adamw> anything else?
16:53:36 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=620635 accepted blocker
16:53:36 <jlaska> who has the action? maintainer?
16:53:37 <buggbot> Bug 620635: medium, low, ---, xjakub, ASSIGNED, antlr3 needs to be rebuilt against python 2.7 in F14 and devel
16:53:38 <Oxf13> yeah, I think a provenpackager should probably go with that proposed action
16:53:43 <poelcat> ack/nak/patch
16:53:50 <adamw> ack
16:53:56 <jlaska> ack
16:54:00 <Oxf13> ack as a blocker.
16:54:15 <poelcat> #agreed https://bugzilla.redhat.com/show_bug.cgi?id=620635 accepted blocker
16:54:16 <buggbot> Bug 620635: medium, low, ---, xjakub, ASSIGNED, antlr3 needs to be rebuilt against python 2.7 in F14 and devel
16:54:29 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=628528
16:54:30 <buggbot> Bug 628528: medium, low, ---, peter.hutterer, NEW, Emulating middle button doesn't work anymore.
16:54:56 <mcepl> Oxf13: I will try to rebuild antlr3
16:55:14 <Oxf13> mcepl: ok.  First we need to know if anything actually depends on antlr3-python
16:56:07 <mcepl> Oxf13: repoquery says that nothing
16:56:19 <jlaska> we requested more info on this bug last week ...
16:56:19 <poelcat> which bug on we on?
16:56:25 <jlaska> #topic
16:56:30 <jlaska> reading to see if we have the right info
16:56:33 <Oxf13> we got more info from the maintainer it seems
16:56:47 <Oxf13> and given his rational, I'd not accept this as a blocker, but it would need relnotes
16:56:48 <jlaska> is this another case of adding peter's info to release notes?
16:56:54 <jlaska> Oxf13: yeah
16:57:02 <adamw> yep, this is clearly not a blocker
16:57:03 <jlaska> it seems like an intentional  behavior change
16:57:36 <adamw> yeah, i understand it better now
16:57:36 <jlaska> adamw and mcepl appear to have started the release note process in that bz
16:57:42 <jlaska> who has the ball on release noting
16:57:42 <poelcat> proposed #agreed https://bugzilla.redhat.com/show_bug.cgi?id=628528 is not accepted as a blocker and should be set for release notes
16:57:44 <buggbot> Bug 628528: medium, low, ---, peter.hutterer, NEW, Emulating middle button doesn't work anymore.
16:57:46 <jlaska> ack
16:57:48 * jlaska phone
16:57:57 <adamw> it'll only affect systems with mouse-y devices with two buttons that are handled by evdev, which is quite rare
16:58:11 <adamw> probably only systems with two-button nipple arrangements
16:58:23 <adamw> many touchpads have only two buttons, but they're handled by synaptics
16:58:33 <adamw> so it's just a documentation issue.
16:58:56 <adamw> mcepl: are you doing the doc for this or should I?
16:59:18 <mcepl> I was pinging around #fedora-docs about it, but I haven't got any definite answer (or at least I don't see any results on the bug)
16:59:45 <poelcat> #agreed https://bugzilla.redhat.com/show_bug.cgi?id=628528 is not accepted as a blocker and should be set for release notes
16:59:46 <buggbot> Bug 628528: medium, low, ---, peter.hutterer, NEW, Emulating middle button doesn't work anymore.
17:00:51 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=629192
17:00:52 <buggbot> Bug 629192: medium, low, ---, rosset.filipe, NEW, Twitter isn't functioning
17:01:37 <adamw> desktop list has been discussing this
17:01:56 <adamw> likely it'll be handled by dropping pino and adding a release note saying to try a different client, but there's a chance we'll replace pino with gwibber
17:01:59 <adamw> either way, it's being handled
17:02:11 <adamw> so we don't have much action to do here
17:02:54 <adamw> just ask them to complete whatever they decide to do in time for tc1 i guess
17:03:26 <poelcat> remain a blocker or not?
17:03:47 <adamw> yes, it's still a blocker until they actually drop pino from comps
17:04:02 <ajax> https://admin.fedoraproject.org/updates/pm-utils-1.3.1-2.fc14 , fwiw
17:04:35 <adamw> ajax: thanks
17:04:50 <jlaska> adamw: thanks for monitoring this one
17:05:12 <jlaska> ajax: adamw: https://bugzilla.redhat.com/show_bug.cgi?id=641421
17:05:13 <buggbot> Bug 641421: medium, low, ---, relnotes, NEW, Add release note indicating that vbetool will no longer be installed by default
17:05:22 <jlaska> I gather I need to follow-up to someone (or the docs team) as well?
17:06:02 <jlaska> adamw: poelcat: so we agree on #topic bug now ... does it have the Accepted whiteboard entry so we don't 'review' it again next week
17:06:02 <adamw> well, that bug should be assigned to docs team so someone should pick it up
17:06:09 <adamw> jlaska: it already had it
17:06:16 <jlaska> adamw: k
17:06:17 <adamw> jlaska: but we need to review accepted issues to make sure they're progressing
17:06:41 <jlaska> adamw: sure
17:06:48 <adamw> next bug
17:06:49 <adamw> ?
17:06:49 <jlaska> topic for antoher time ... we can move on
17:06:52 <mcepl> jlaska: I am pinging on #fedora-docs about https://bugzilla.redhat.com/show_bug.cgi?id=628528 but it doesn't seem to be the most active channel on Freenode
17:06:53 <buggbot> Bug 628528: medium, low, ---, relnotes, NEW, Release note needed: Middle mouse button emulation now disabled by default for evdev devices
17:07:18 <jlaska> mcepl: no it's not, the list might be better
17:07:27 * adamw re-assigned that bug to release notes component
17:07:28 <jlaska> mcepl: we can tag team :)
17:07:41 <poelcat> proposed #agreed https://bugzilla.redhat.com/show_bug.cgi?id=629192 is in progress and being handled on desktop list
17:07:42 <buggbot> Bug 629192: medium, low, ---, rosset.filipe, NEW, Twitter isn't functioning
17:07:57 <jlaska> ack'a'roo
17:08:07 <adamw> ack
17:08:10 <poelcat> #agreed https://bugzilla.redhat.com/show_bug.cgi?id=629192 is in progress and being handled on desktop list
17:08:11 <buggbot> Bug 629192: medium, low, ---, rosset.filipe, NEW, Twitter isn't functioning
17:08:15 <mcepl> +1
17:08:15 <Oxf13> ack
17:08:26 <poelcat> #topic KDE blocker bus?
17:08:30 * mcepl uses spectrum anyway ;)
17:08:31 <poelcat> bugs
17:08:35 <poelcat> why are these here?
17:08:39 <poelcat> are we discussing them?
17:08:45 <adamw> historically we always did.
17:08:57 <jlaska> I was going to say, we didn't exclude them in the past
17:09:05 <poelcat> okay
17:09:10 <jlaska> is that the right approach now given our understanding of how the desktops line up?
17:09:15 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=637064
17:09:16 <buggbot> Bug 637064: high, low, ---, jreznik, ASSIGNED, PolicyKit-KDE crash during shutdown
17:09:29 <adamw> for f14 i think we just go with what we've gone with so far
17:09:34 <jlaska> agreed
17:09:51 <jlaska> and we can course correct after release
17:10:19 <adamw> this is a blocker under criterion "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ) ", i'd say, looks like a fix is available
17:10:37 <jlaska> yeah, the reporter of this issue indicates the problem is resolved by either this build, or the new PackageKit
17:11:11 <jlaska> so, is this a default desktop offering
17:11:21 <jlaska> if so ... blocker, if not ... NTH (am I correct)
17:11:22 <adamw> rdieter's coming to provide us with KDE Clue
17:11:36 <adamw> jlaska: not entirely =) kde issues have always counted as blocker before so i'm rolling with that for 14
17:11:42 * jlaska prepares the KDE paper banner for rdieter to bust through
17:11:49 <rdieter> the new builds referenced in the bug should fix it, afaik.
17:12:08 <rdieter> ha
17:12:27 <adamw> rdieter: i don't quite see how a PackageKit update fixes it?
17:12:38 <rdieter> adamw: me either, honestly
17:12:43 <jlaska> it may just be one of many updates included when they yum updated?
17:12:45 <adamw> yeah
17:12:59 <adamw> so we probably want that build radek did submitted as an update
17:13:05 <adamw> and to ask the reporter what the hell he's smoking
17:13:43 <rdieter> agreed, the fixes look good to me (having seen the patch), yay valgrind
17:14:21 <adamw> rdieter: ok, so if you can get them submitted as updates and +1ed that'll be great
17:14:31 <rdieter> adamw: will do
17:14:33 <adamw> propose #agreed accepted as a blocker
17:14:40 <adamw> propose #action rdieter to supervise pushing of fixes
17:14:54 <poelcat> proposed #agreed https://bugzilla.redhat.com/show_bug.cgi?id=637064 accepted as blocker; rdieter to supervise pushing of fixes
17:14:55 <buggbot> Bug 637064: high, low, ---, jreznik, ASSIGNED, PolicyKit-KDE crash during shutdown
17:14:58 <poelcat> ack/nak/patch
17:15:00 <adamw> ack
17:15:03 <jlaska> ack
17:15:17 * jlaska still fuzzy on which desktops fall under blocker criteria, and NTH criteria
17:15:30 <poelcat> #agreed https://bugzilla.redhat.com/show_bug.cgi?id=637064 accepted as blocker; rdieter to supervise pushing of fixes
17:15:31 <buggbot> Bug 637064: high, low, ---, jreznik, ASSIGNED, PolicyKit-KDE crash during shutdown
17:15:41 <Oxf13> since the KDE desktop is on the DVD, it seems pretty clear to me that it is blocker
17:15:41 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=612581
17:15:43 <buggbot> Bug 612581: medium, low, ---, sochotni, ASSIGNED, Review Request: spacewalk-backend - Common programs needed to be installed on the Spacewalk servers/proxies
17:15:51 <Oxf13> KDE is also an "official" live media
17:16:06 <jlaska> so GNOME + KDE fit the bill for blocker release criteria?
17:16:06 <Oxf13> we just also list it in the spins section because KDE likes to get all the advertising it can get :)
17:16:30 <Oxf13> jlaska: until somebody manages to pass a proposal that KDE doesn't count as blocker
17:16:33 <adamw> oh, that's all the KDE blockers we have?
17:16:36 <Oxf13> (which would mean probably dropping it from the DVD)
17:16:37 * poelcat thinks we should discuss this topic outside of this meeting
17:16:47 <jlaska> poelcat: you're right, sorry
17:16:58 <adamw> ok, this shouldn't be a blocker any more
17:16:59 <poelcat> or add to the retrospective page
17:17:14 <jlaska> "I'm still working on this. My ETA is one month."
17:17:16 <adamw> it's only a blocker because it blocks 639391, but it doesn't need to block that any more as spacewalk-certs-tools got regressed
17:17:28 <adamw> so we can stop this bug blocking 639391 now
17:17:52 <Oxf13> +1
17:17:54 <poelcat> proposed #agreed remove https://bugzilla.redhat.com/show_bug.cgi?id=612581 from blocker list
17:17:55 <buggbot> Bug 612581: medium, low, ---, sochotni, ASSIGNED, Review Request: spacewalk-backend - Common programs needed to be installed on the Spacewalk servers/proxies
17:18:00 <adamw> ack
17:18:04 <jlaska> ack
17:18:07 <poelcat> #agreed remove https://bugzilla.redhat.com/show_bug.cgi?id=612581 from blocker list
17:18:07 <adamw> (well, it's not *on* the blocker list exactly, but w/e)
17:18:08 <buggbot> Bug 612581: medium, low, ---, sochotni, ASSIGNED, Review Request: spacewalk-backend - Common programs needed to be installed on the Spacewalk servers/proxies
17:18:19 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=639393
17:18:20 <buggbot> Bug 639393: medium, low, ---, fabian, NEW, Broken dependency: qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit)
17:18:49 <adamw> so given the discussion on -test list we should now downgrade this to NTH
17:18:53 <adamw> as it's a non-media dep issue
17:18:54 <jlaska> NTH
17:19:41 <poelcat> proposed #agreed https://bugzilla.redhat.com/show_bug.cgi?id=639393 based on test-list discussion downgrade this bug to NTH
17:19:42 <buggbot> Bug 639393: medium, low, ---, fabian, NEW, Broken dependency: qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit)
17:19:46 <poelcat> ack/nak/patch
17:19:47 <jlaska> ack
17:20:09 * jlaska just re-re-confirmed it isn't on media
17:20:23 <poelcat> #agreed https://bugzilla.redhat.com/show_bug.cgi?id=639393 based on test-list discussion downgrade this bug to NTH
17:20:24 <buggbot> Bug 639393: medium, low, ---, fabian, NEW, Broken dependency: qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit)
17:20:39 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=640271
17:20:41 <buggbot> Bug 640271: medium, low, ---, r.landmann, ASSIGNED, Fedora 14 installation guide references "RHEL" in examples
17:21:11 <poelcat> does it meet the criteria for a blocker?
17:21:53 <adamw> no, we have nothing covering docs
17:22:10 * jlaska proposed this
17:22:34 <jlaska> is the install-guide on media?
17:22:36 * jlaska doesn't think so
17:22:46 <jlaska> no
17:22:53 <poelcat> proposed #agreed https://bugzilla.redhat.com/show_bug.cgi?id=640271 remove from blocker list; there is no current critiera for docs and it appears the issue is already fixed
17:22:54 <buggbot> Bug 640271: medium, low, ---, r.landmann, ASSIGNED, Fedora 14 installation guide references "RHEL" in examples
17:23:06 <jlaska> hmm, good enough ... as it will be fixed
17:23:12 <poelcat> ack/nak/patch?
17:23:16 <adamw> it's not fixed yet
17:23:16 <adamw> ack
17:23:31 <jlaska> rephrased, fix inprogress
17:24:18 <jlaska> reluctant ack
17:24:19 <poelcat> #agreed https://bugzilla.redhat.com/show_bug.cgi?id=640271 remove from blocker list; there is no current critiera for docs and it appears a fix is in progress
17:24:20 <buggbot> Bug 640271: medium, low, ---, r.landmann, ASSIGNED, Fedora 14 installation guide references "RHEL" in examples
17:24:34 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=640309
17:24:35 <buggbot> Bug 640309: medium, low, ---, r.landmann, ASSIGNED, F-14 installation guide documents unsupported 'telnet' method
17:24:51 <jlaska> I gather the same decision applies here
17:24:56 <poelcat> another docs bug
17:25:05 <jlaska> this comes from test@ discussion regarding the removed 'telnet' installation method
17:25:12 <Oxf13> up arrow; enter
17:25:30 <jlaska> yeah, I guess this is the same as how we've handled release notes issues
17:25:39 <poelcat> #agreed https://bugzilla.redhat.com/show_bug.cgi?id=640309 remove from blocker list; there is no current critiera for docs and it appears a fix is in progress
17:25:39 <jlaska> we initiate the process, but don't block on the outcome
17:25:40 <buggbot> Bug 640309: medium, low, ---, r.landmann, ASSIGNED, F-14 installation guide documents unsupported 'telnet' method
17:25:54 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=640951
17:25:55 <buggbot> Bug 640951: medium, low, ---, rvykydal, ASSIGNED, IPV4 DHCP configuration is always used in stage 2 network enablement.
17:27:05 <adamw> so, it seems anaconda team has an internal freeze or something
17:27:16 <adamw> and at this point they won't accept fixes into their f14 branch unless they're for blocker or nth bugs
17:27:26 <adamw> so radek's been proposing several of his fixes in order to get them in final...
17:27:37 <adamw> dlehman: ping?
17:27:50 <Oxf13> hrm.
17:28:01 <Oxf13> this seems like a pretty big behavior change
17:28:09 <dlehman> right. you guys will scream if we de-stabilize at this point, right?
17:28:10 <Oxf13> is this a regression from previous releases, or just something it never did?
17:28:22 <adamw> Oxf13: the concept doesn't really apply as we didn't have nm-c-e in previous releases
17:28:28 <adamw> this whole area differs significantly from f13
17:28:28 <dlehman> correct
17:28:28 <Oxf13> dlehman: more like cry into a bucket of beer
17:28:39 <jlaska> patch -https://bugzilla.redhat.com/attachment.cgi?id=452081
17:28:43 <adamw> i'm for taking sane fixes at this point, since we're prior to tc1
17:29:06 <Oxf13> I'm still trying to wrap my head around "is this a bugfix, or is this further feature enablement"
17:29:15 <Oxf13> what did we have at feature freeze?
17:29:24 <jlaska> it's a bugfix to a feature
17:29:30 <adamw> it's clearly a bug fix
17:29:39 <adamw> the feature here is 'do network configuration with nm-c-e'
17:29:52 <Oxf13> wait, this is post-install network bring up?
17:29:55 <Oxf13> not in-install network bring up?
17:30:05 <adamw> this is during install, i believe
17:30:14 <jlaska> Oxf13: it's kind of both I think
17:30:26 <Oxf13> hrm.
17:30:27 <rvykydal_> yes, during install
17:30:27 <jlaska> rvykydal_: around still?
17:30:43 <adamw> the procedure is to boot the installer, specify a network config that uses static addressing, then check on what actually happened: if a DHCP server is present it'll have used DHCP, not the static config you specified
17:30:45 <Oxf13> screwing with how the network works during install is always "fun"
17:31:12 <Oxf13> but I can see this as a regression in behavior (if not in technology) from previous releases
17:31:15 <Oxf13> so +1 blocker.
17:31:15 * adamw is trying to think of ways this could go wrong, given that the change is fairly minimal
17:31:21 * adamw is +1 nth on this
17:31:28 <adamw> (with the effect that we'll take the fix, since it's already available)
17:31:29 <jlaska> does this block proceeding with the staticly configured network install?
17:31:41 <adamw> jlaska: i think it would kind of depend on how your network is set up
17:31:42 <jlaska> (assuming no DHCP server is talking on the subnet)
17:31:58 <adamw> rvykydal_: if no dhcp server is present does it fail or use the static config?
17:32:04 <rvykydal_> no
17:32:35 <adamw> i think the only outright failure case is if a dhcp server is present but the network is configured to restrict the connections of clients using DHCP - i.e. you need to specify a static config to actually get the access you need to install...
17:33:10 <rvykydal_> adamw, yes
17:33:23 <rvykydal_> adamw, the only case I was able to think of
17:33:27 <jlaska> patch reviewed?
17:33:40 <jlaska> rvykydal_: dlehman: I mean, you guys are happy with it?
17:33:42 <adamw> so yeah, i think the impact here isn't huge so it's not a blocker...being a daredevil i still want to +1 nth so we take the fix, but i'm okay if we don't
17:34:20 <rvykydal_> jlaska, patch is reviewed, it's already on master
17:34:22 <poelcat> i see one NTH and one blocker
17:34:39 <adamw> Oxf13: want to revise your vote given the above?
17:35:12 <jlaska> can anywone test this for us?
17:35:22 <adamw> jlaska: i think anyone can test it
17:35:22 <Oxf13> Honestly I don't think its all that uncommon to have DHCP on a network, but desire static for a particular set of systems
17:35:42 <Oxf13> and since it is a behavior regression from 13, and in the installer, I see this as more of a blocker
17:36:03 <adamw> ok
17:36:08 <adamw> well it's kind of an academic distinction
17:36:16 <jlaska> adamw: sure, I was asking more how to do this -- "network is configured to restrict the connections of clients using DHCP"
17:36:21 <adamw> since the patch is already available, if we make it *either* NTH *or* blocker it's going to go in
17:36:39 * adamw will +1 blocker if it moves things along
17:36:49 <jlaska> I'm happy with NTH for this
17:37:11 <jlaska> I'd like for some test help from someone who can reproduce this failure
17:37:13 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=640951 set as accepted blocker; patch ready, need new build and bodhi update
17:37:14 <buggbot> Bug 640951: medium, low, ---, rvykydal, ASSIGNED, IPV4 DHCP configuration is always used in stage 2 network enablement.
17:37:40 <jlaska> rvykydal_: I take it you were able to reproduce the failure, since you filed the bug?
17:37:42 <rvykydal_> jlaska, no problem, I can reproduce, I tested it locally
17:37:48 <adamw> jlaska: you don't need to reproduce the odd case i described to check
17:38:00 <adamw> jlaska: all you need to do is specify a static config then use a console to see if the static config was actually used
17:38:04 <poelcat> ack/nak/patch?
17:38:06 <adamw> ack
17:39:02 <Oxf13> ack
17:39:22 <poelcat> #agreed https://bugzilla.redhat.com/show_bug.cgi?id=640951 set as accepted blocker; patch ready, need new build and bodhi update
17:39:23 <buggbot> Bug 640951: medium, low, ---, rvykydal, ASSIGNED, IPV4 DHCP configuration is always used in stage 2 network enablement.
17:39:34 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=584328
17:39:36 <buggbot> Bug 584328: medium, low, ---, dlehman, ASSIGNED, AttributeError: 'NoneType' object has no attribute 'name'
17:39:52 <Oxf13> how timely
17:39:55 <Oxf13> there was just an update to this bug
17:40:07 <jlaska> adamw: I understand that, thanks
17:40:31 * jlaska has a lot of experience testing static+dhcp oddities with loader .. just was looking for some extra details
17:40:36 <adamw> ok
17:40:45 <adamw> so this one we already accepted as blocker we're just tracking progress
17:41:18 <dlehman> correct
17:41:23 <adamw> dlehman posted a status update so we're in good shape...
17:41:27 <Oxf13> and progress is being made
17:41:44 <adamw> should just note that we'd really like to have fixes by monday/tuesday to make tc1, and we need to have the fixes by a week after that to make rc1
17:42:16 <dlehman> yep -- only wildcard is upstream kernel/lvm2 acceptance
17:42:42 <dlehman> we should probably make a separate bug for those components so they have the fire under them specifically
17:42:59 <jlaska> yes!
17:43:05 <adamw> is there actually any change required in anaconda/
17:43:06 <adamw> ?
17:43:56 <adamw> dlehman: ^^
17:45:14 <dlehman> no
17:45:22 <dlehman> pyblock, kernel, lvm2
17:45:26 <adamw> ok
17:45:37 <adamw> so we can re-assign the bug to one of those components and create new bugs blocking this one for the other two?
17:46:21 <jlaska> I'll be happy to clone 2 new bugs for kernel + lvm2
17:46:41 <jlaska> dlehman: I'll catch up with you after in case there is any relevant info you think they'd need to get started
17:47:02 <adamw> ok, proposed #agreed this bug is in active development, #action jlaska to re-assign bug to pyblock and file new bugs for kernel and lvm2 blocking this bug, assign to appropriate people
17:47:08 <jlaska> #action jlaska - clone 584328 to track additional changes required in kernel and lvm2
17:47:42 <jlaska> ack
17:47:47 <Oxf13> acky
17:48:04 <poelcat> can someone else drive from here on out?
17:48:14 <adamw> #agreed 584328 is in progress, jlaska and dlehman to drive
17:48:18 <adamw> poelcat: got it
17:48:23 <adamw> poelcat: what's the URL of the list you're working from?
17:48:32 <jlaska> see #topic
17:48:37 <adamw> oh ueaj
17:48:42 <poelcat> adamw: topic ... in order
17:48:51 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=627388
17:48:52 <buggbot> Bug 627388: high, low, ---, msivak, ASSIGNED, VNC install ignores password
17:49:28 * adamw agrees with martin, not a blocker
17:49:30 <jlaska> I agree with Martin's feedback in comment#13 of this issue
17:49:54 <adamw> nth, or not even that?
17:50:00 <jlaska> not yet
17:50:13 <jlaska> I'd want to know what the *real* problem and proposed solution is first
17:50:31 <adamw> let's just mark it as a rejected blocker for now and move on...
17:50:34 <jlaska> proposed 627388 - remove from blocker list - when root cause is available, may revisit for NTH or common_f14_bugs
17:50:36 <adamw> ack
17:50:49 <Oxf13> ack
17:51:00 <jlaska> #agreed https://bugzilla.redhat.com/show_bug.cgi?id=627388 - remove from blocker list.  When root cause is available, may revisit for NTH or common_f14_bugs
17:51:01 <buggbot> Bug 627388: high, low, ---, msivak, ASSIGNED, VNC install ignores password
17:51:12 <jlaska> adamw: any objections if I keep #topic flowing while you secretize?
17:51:32 <adamw> go ahead
17:51:34 * jlaska would like to contribute some how :)
17:51:41 <jlaska> alrighty ...
17:51:42 <jlaska> next up
17:51:43 <Oxf13> well
17:51:45 <mcepl> adamw: is the answer to https://bugzilla.redhat.com/show_bug.cgi?id=628528#c21 ... "use comment 8"?
17:51:46 <buggbot> Bug 628528: medium, low, ---, relnotes, NEW, Release note needed: Middle mouse button emulation now disabled by default for evdev devices
17:51:52 <jlaska> Oxf13: /
17:51:53 <jlaska> ?
17:52:14 <adamw> mcepl: yes
17:52:16 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=627789
17:52:17 <buggbot> Bug 627789: medium, low, ---, bcl, MODIFIED, Error setting up repository - 16, Device busy
17:52:31 <Oxf13> define "secretize" ?  If it's stuff with #foo in this channel, don't switch topics, it screws up with meeting notes format
17:52:40 <adamw> we've been skipping MODIFIED and ON_QA so far isn't it?
17:52:41 <Oxf13> if secretize is work outside of the meetbot, then have at it
17:52:49 <jlaska> I believe we are in good shape here ... this just needs to be VERIFIED
17:52:49 <adamw> Oxf13: secretary stuff - updating the bugs
17:52:53 <Oxf13> kk
17:53:09 <bcl> jlaska: yep. Fix is in 14.18
17:53:11 <jlaska> Okay, I will skip remaining MODIFIED and ON_QA bugs
17:53:25 <adamw> of course we should take anaconda 14.18 in tc1 =) (or later)
17:53:54 <jlaska> available now - https://admin.fedoraproject.org/updates/anaconda-14.18-1.fc14
17:54:00 <jlaska> #info available for testing (see https://admin.fedoraproject.org/updates/anaconda-14.18-1.fc14)
17:54:12 <jlaska> okay, skipping ON_QA bug ...
17:54:14 <jlaska> next issue ...
17:54:15 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=635821
17:54:16 <buggbot> Bug 635821: medium, low, ---, anaconda-maint-list, ASSIGNED, Attempting to submit (scp or bugzilla) an exception report fails if networking not active
17:55:28 <jlaska> I thought we accepted this last week, but I don't see the Accepted whiteboard entry
17:55:30 <adamw> so gavin's been working on this
17:55:44 <adamw> jlaska: it's there, after the commonbugs entry
17:55:52 <jlaska> oh, I see, thanks
17:55:59 <jlaska> so we're waiting for a revised patch from gavin
17:56:12 <adamw> looks like it
17:56:21 <adamw> we can probably note the deadlines in a comment, other than that, no action needed i think
17:56:37 <jlaska> #action gavin - provide updated patchset to include in F-14-TC1
17:56:43 <jlaska> good call, a ping couldn't hurt
17:57:22 <adamw> done
17:57:27 <jlaska> thanks, next up ...
17:57:28 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=636099
17:57:29 <buggbot> Bug 636099: medium, low, ---, rvykydal, NEW, [anaconda] keys-wlan0 world readable after wireless network install
17:57:50 <jlaska> wow, hard to believe now with complete NM support, you can do a fully wireless install
17:58:30 <adamw> i'm certainly +1 nth on this
17:58:47 <Oxf13> seems pretty irresponsible to ship a distro with a leaked key like that.
17:58:49 <adamw> hard to +1 blocker as it's not covered by the criteria...unless we call it a 'high' severity issue in anaconda (which is a critical component)
17:58:50 <jlaska> uh no's ... loader/net.c
17:59:19 <adamw> really does look like a safe change though
17:59:22 <adamw> all it does is set a mode on one file
17:59:27 <jlaska> nothing in loader is a safe change :)
17:59:39 <adamw> =)
17:59:44 <jlaska> but yeah, on the surface it looks sane, and rvykydal_ tested the fix (thank you)
17:59:56 <adamw> proposal - let's call it NTH on the basis of path of least resistance
18:00:11 <adamw> but with the understanding that means it'll go straight in, as the patch is available
18:00:11 <Oxf13> hark, is that gaming the system I hear?
18:00:15 <adamw> yes indeed it is!
18:00:31 <adamw> well, it's more 'dumbly going with the current system instead of proposing another new bloody criterion'
18:00:56 <Oxf13> I'd rather see this as a blocker.  It's a clear security issue, that we know about before hand.  Would you really want to stand in front of people and say "yea, we knew we were leaking security here, and that there was no way to fix this in an update, but we shipped anyway.  lolz!"
18:01:00 <jlaska> well, is it a security risk or not?
18:01:23 <adamw> yeah, it clearly is.
18:01:43 <adamw> anyone with access to the system gets to know the key of the wireless network.
18:01:46 <jlaska> I don't see criteria around security issues, may just be missing, but that's something we should consider for a criteria update
18:01:54 <adamw> yeah, there aren't any. we should probably add some.
18:02:09 <jlaska> okay, we'll take that offline
18:02:10 <adamw> i think oxf13 just volunteered to write security criteria ;)
18:02:10 <Oxf13> (this is one of my major concerns with the release criteria system, if we don't have the ability to look at an issue and as a group decide "you know, we aren't going to ship like that, even though it doesn't match any of our existing criteria")
18:02:27 <adamw> Oxf13: well, we do, there's another dodge - call it high severity, then it makes the catch-all
18:02:29 <jsmith> Oxf13: We *absolutely* have the ability to do that...
18:02:40 <adamw> 'A bug in a Critical Path package that:
18:02:40 <adamw> * Cannot be fixed with a future rawhide update
18:02:40 <adamw> * Has a severity rating of high or greater and no reasonable workaround (see definition of severity and priority)'
18:02:54 <adamw> it shouldn't say 'rawhide', heh.,
18:02:59 <Oxf13> jsmith: "we" as a group seem unable to make that happen.  This has occurred on multiple occasions now
18:03:14 <jlaska> a good topic, but it's off topic
18:03:24 <adamw> well, we've proposed new criteria instead. which is a much better way to do it, because it means we won't miss the same thing in future.
18:03:25 <jlaska> let's not derail on the merits of having release criteria
18:04:06 <jlaska> proposed #agreed 636099 - accepted as a blocker due to possible security risk.  #action _____ - propose updated final release criteria around security issues
18:04:08 <adamw> if it's going to make jesse happy i'm fine with rating this 'high' severity and calling it f14blocker under the above catch-all
18:04:22 <jlaska> ack/nak/patch
18:04:32 <adamw> ack
18:04:33 <Oxf13> ack
18:04:54 <dlehman> is that it for anaconda?
18:04:55 <jlaska> #agreed 636099 - accepted as a blocker due to possible security risk.
18:05:00 <jlaska> dlehman: yeah
18:05:05 <dlehman> ok
18:05:09 <jlaska> dlehman: ack/nak/patch from you?
18:05:09 * dlehman goes afk for a bit
18:05:12 <jlaska> k
18:05:27 <jlaska> anyone want to take the #action here, otherwise, it does into the queue
18:05:30 <dlehman> if someone can post a link to mailman archive i can take a look
18:05:35 <dlehman> I can't get on vpn today
18:05:37 <jlaska> https://www.redhat.com/archives/anaconda-devel-list/2010-October/msg00029.html
18:06:14 <jlaska> #action jlaska - propose updated final release criteria around security issues to test@ (636099)
18:06:30 <jlaska> skipping an ON_QA bug ...
18:06:34 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=640951
18:06:35 <buggbot> Bug 640951: medium, low, ---, rvykydal, ASSIGNED, IPV4 DHCP configuration is always used in stage 2 network enablement.
18:06:58 <jlaska> and we already discussed this
18:07:01 <adamw> yup
18:07:04 <dlehman> jlaska: patch looks ok. will ack when I get to my mail
18:07:09 <jlaska> dlehman: thanks
18:07:17 <jlaska> so that's it for installer issues on F14Blocker
18:07:21 <jlaska> now a virt bug ...
18:07:23 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=641338
18:07:24 <buggbot> Bug 641338: medium, low, ---, jforbes, NEW, f14 qemu-kvm guests boot very slowly
18:07:38 <adamw> rdieter: you're on again =)
18:07:50 <adamw> i believe this is KDE specific, but in the context of the KDE live image, yeah, i confirm this, been seeing it since beta at least
18:08:03 <jlaska> according to the latest comment, this seems more qemu?
18:08:14 <rdieter> oh, I forgot to ask poelcat exactly what he was trying to use/boot
18:08:17 <adamw> not sure where the bug is, but it only happens with KDE afaik
18:08:21 <jlaska> poelcat: still around?
18:08:43 <adamw> poelcat's case doesn't match the criteria btw
18:08:51 <adamw> it says 'the previous release', which means *one* release prior
18:08:58 <adamw> so only f14-on-f13 meets the criterion, not f14-on-f12
18:09:11 <rdieter> well, I'm on f13
18:09:18 <adamw> yeah, just noting a wrinkle in john's case
18:09:23 <rdieter> ok
18:09:26 <jlaska> true true, we don't account for f14 on f12
18:10:19 <jlaska> sounds like we need more info on this issue then
18:10:25 <adamw> well
18:10:28 <jlaska> whether it's limited to KDE on a f13 host
18:10:31 <adamw> rdieter and I confirm it with the KDE image
18:10:37 <adamw> i'm f14-on-f14, not f14-on-f13
18:10:39 <jlaska> alright, we'll stick with what we know for now
18:10:46 <adamw> i can boot GNOME, XFCE and LXDE fine though
18:11:16 <jlaska> want me to grab jforbes?
18:11:41 * jlaska grabs
18:12:22 <jlaska> anything else we can decide on with this bug while waiting?
18:12:58 <jlaska> I think this is rough enough to warrant further review by someone in the virt space
18:13:11 <adamw> yeah, probably in collaboration with the KDE team
18:13:21 <adamw> i think it has *something* to do with how KDE renders but i dunno what
18:13:40 <jlaska> is this something where trying different xdrivers would help rule that in/out?
18:13:56 <adamw> given that it's in kvm, not really
18:14:02 <jlaska> oh right, that issue
18:14:03 <adamw> since there's exactly one driver we can use =)
18:14:10 <jlaska> yuppers
18:14:10 <adamw> oh, although i think ajax may have fixed that recently in fact
18:14:22 <jlaska> yeah, that's right robatino was testing that
18:14:29 <adamw> maybe once we have that fix we can test with vesa
18:14:44 <adamw> but yeah, i think we need more info here
18:14:45 <jlaska> okay, so jforbes may be out today or lunching or busy
18:14:49 <jlaska> ...
18:15:16 <ajax> i'm pretty sure the most recent xserver build fixes robatino's kvm issue
18:15:22 <jlaska> proposed #agreed 641338 - keep on list pending feedback from KDE + Virt teams.  Review next week for action
18:15:32 <ajax> in that, i tested it, and the server no longer aborts
18:15:40 <jlaska> ajax: that's a plus :)
18:16:06 <jlaska> ack/nak/patch anyone?
18:16:17 <adamw> ack
18:16:25 <Oxf13> ack
18:16:38 <jlaska> #agreed 641338 - keep on list pending feedback from KDE + Virt teams.  Review next week for action
18:17:02 <jlaska> okay, that's it for F14Blocker
18:17:08 <jlaska> ready for some -accepted NTH action?
18:17:11 <adamw> so i have a list of NTH bugs which haven't been reviewed
18:17:15 <mcepl> Oxf13: that antlr3 bug seems to be complicated ... I am not a maven guru. Will try to ask around, but certainly it takes a bit of time
18:17:33 * jlaska shudders ... maven
18:17:33 <adamw> #link http://tinyurl.com/36egbjc
18:17:41 <jlaska> adamw: take it away
18:17:54 <jlaska> apologies for the number of issues :)
18:17:57 <adamw> i propose we just agree that all the dependency bugs are accepted
18:18:03 <adamw> no point taking them one by one
18:18:08 <jlaska> great point
18:18:10 <Oxf13> +1
18:18:21 <jlaska> we discussed that procedure in the last meeting, and reached consensus on test@ list
18:18:37 <jlaska> +1 (if that wasn't clear)
18:18:41 <adamw> ok
18:18:47 <adamw> so i'll just go with the other issues one-by-one
18:18:57 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=638634
18:18:58 <buggbot> Bug 638634: medium, low, ---, rvykydal, ASSIGNED, computer name does not stick on Live CD
18:19:20 <adamw> so if you set a hostname during live install it doesn't get applied to the installed system
18:19:24 <adamw> seems like a reasonable fix to take
18:19:27 <jlaska> adamw: can you hit 641308 next while rvykydal_ is still online?
18:19:48 * jlaska looks @ patch
18:20:02 <adamw> this is another rvyk one
18:20:04 <jlaska> #info patch - http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=5161a324ad2cf2be636a6cd330390e7f05971
18:20:09 <adamw> and yup i'll queue up rvyk's
18:20:12 <jlaska> rvykydal_: kudos gets process points this meeting :)
18:20:14 <adamw> dlehman: what's your take on this?
18:21:05 <Oxf13> so again, is this a regression in behavior?  If so, +1 blocker.  If not +1 NIH
18:21:12 <adamw> yeah, it's a regression associated with the nm changes
18:21:16 <adamw> this worked in previous
18:21:44 <Oxf13> +1 blocker then
18:22:43 * jlaska struggling with which criteria would be affected by this issue
18:23:18 <adamw> well, depending on your particular environment a system with a wrong hostname may not be entirely 'functional'
18:23:25 <adamw> i'm thinking network login situation maybe, whatever...
18:23:33 <adamw> but i'm still kinda feeling NTH-y on this one
18:23:59 <jlaska> I'm NTH as well .. I'm not aware of having the hostname set as the default value of 'localhost' will break anything
18:23:59 <adamw> again, it's kind of an academic distinction
18:24:25 <adamw> ok, so that's 2 NTH 1 blocker, call it NTH
18:24:41 <adamw> #agreed 638634 accepted as nice-to-have, please take fix into next anaconda buiild
18:25:22 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=641308
18:25:23 <buggbot> Bug 641308: is not accessible.
18:25:39 <adamw> er, should we unlock this bug? :)
18:26:16 * jlaska was going to do that ... yeah
18:26:18 <notting> meh. it's workaroundable with a "don't do that" explanation
18:26:54 <adamw> well
18:27:09 <adamw> rvykydal_: what do you have to do during install to make it work?
18:27:25 <adamw> there's also the kickstart case in the initial bug report
18:27:34 <adamw> which seems like maybe a more realistic scenario
18:27:43 <jlaska> iiuc, you have to check "[X] Connect automatically" in order for the ONBOOT=yes value to be set for post-install networking to be enabled
18:27:56 <jlaska> so if you just close the nm-c-e dialog, you get networking for the install, but not post-install
18:28:36 * adamw on the fence
18:28:43 <jlaska> I'm not thrilled about it
18:28:53 <jlaska> but at least it's making post-install networking more possible
18:28:54 <jlaska> not less
18:29:09 <jlaska> so we'll have fewer issues with folks indicating anaconda didn't setup their system for networking
18:29:27 <jlaska> so after this fix ... *any* time you are prompted for networking during install, it will also enable it for the post-installed system
18:29:41 <jlaska> rvykydal_: can you confirm/deny?
18:29:45 <notting> jlaska: i'm not saying we can't fix it, but it didn't seem blocker-worthy
18:30:05 <adamw> notting: we're reviewing for NTH status now, not blocker status
18:30:07 <jlaska> notting: oh right, I was just thinking through the fix ... not arguing either way
18:30:16 <adamw> these bugs are proposed NTH, not proposed blockers
18:30:17 <Oxf13> I think we want to take this.
18:30:23 <Oxf13> NIH+1
18:30:28 <Oxf13> NTH
18:30:29 <adamw> yeah, looking at the fix i'm inclined to +! NTH
18:30:42 <adamw> since as jlaska says it looks like the patch can only possibly incline more towards networking being enabled
18:30:54 <adamw> so is that three +1 NTH?
18:31:30 <jlaska> NTH +-0
18:31:34 <adamw> ok, +2 wins
18:31:36 <jlaska> :)
18:31:41 <adamw> #agreed 641308 accepted as nice-to-have
18:31:57 <jlaska> adamw: thanks for going out of order with that, was hoping rvykydal_ was still around
18:32:15 <adamw> actually it happened to be in order anyway =)
18:32:17 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=634777
18:32:18 <buggbot> Bug 634777: medium, low, ---, mgracik, NEW, Firstboot does not show translations in hardware profile screen
18:32:37 <adamw> so this is one we asked for more info on last week, and got it
18:32:43 <adamw> based on last week's discussion i think we accept this as NTH
18:32:53 <adamw> since the missed translation is in the fedora text
18:33:13 * jlaska would be interested in understanding which translations are a priority for Fedora
18:33:26 <jlaska> ^--> out of meeting though
18:33:26 <adamw> i think anything in firstboot is a priority as everyone sees it, you can't skip it
18:33:37 <jlaska> I'm not sure
18:33:39 <adamw> throwing a big chunk of un-translated english at people in firstboot strikes me as impolite =)
18:34:13 <jlaska> I agree it's not ideal, I'd like to understand more about the types of translation issues we'd consider blockers
18:34:17 <jlaska> if at all
18:34:31 <adamw> even though we know the smolt profile screen isn't too important, the problem with translation is that it's exactly this text which allows you to make the important/not-important assessment...if we're imagining someone installing fedora in their native language who doesn't speak english, they're going to hit this screen and not know what the hell's going on
18:34:39 <jlaska> i.e. incomplete or poorly maintained translations ... probably wouldn't be justified as blockers
18:34:49 <adamw> ah i see
18:35:00 * jlaska would like to know intent
18:35:01 <adamw> i think in this case the bug is in firstboot itself, the translation is available but not being displayed
18:35:07 <jlaska> which translations are intended to be complete
18:35:09 <adamw> that's a worse case i believe
18:35:39 <jlaska> with regards to NTH ... I'm probably +-0
18:36:04 <jlaska> but I do need to understand more about translations when it comes to blocker-y-ness
18:36:37 <adamw> the pt_BR translation is listed as 100% for firstboot
18:36:48 <jlaska> adamw: ooh, where'd you find that?
18:36:52 <jlaska> share share! :)
18:37:21 <adamw> in transifex
18:37:22 <jlaska> #action jlaska - file fedora-qa ticket to handle investigating and potentially propose release blocker criteria for translations
18:37:28 <adamw> https://translate.fedoraproject.org/projects/p/firstboot/c/master/
18:37:46 * jlaska needs to create a new mozilla keyword bookmark
18:37:48 <jlaska> adamw: thanks for lin
18:37:49 <jlaska> k
18:37:52 <adamw> anyway, remember, we're not on blocker criteria here, we're on nth
18:38:02 <jlaska> right on
18:38:12 <jlaska> lemme revise my vote
18:38:20 <jlaska> I'm NTH +1 then given the transifex data
18:38:20 <adamw> i suspect firstboot just isn't exposing this string as translateable...
18:38:26 <jlaska> could be
18:38:53 <adamw> note igor also checked it, per his comment: "I checked the .PO and the string is translated."
18:38:57 <adamw> so i'm +1
18:39:00 <adamw> so we have this accepted
18:39:45 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=636227
18:39:46 <buggbot> Bug 636227: medium, low, ---, kevin, ASSIGNED, RFE: No mixer applet on XFCE desktop (F14 Beta RC3)
18:39:55 <adamw> not sure why this wasn't reviewed last week...maybe it was and i missed updating the bug
18:40:10 <jlaska> we discussed it didn't we?
18:40:14 * jlaska might be mixing meetings
18:40:26 <adamw> yeah i think we did and i just didn't update the bug
18:40:30 <adamw> so let's mark it as accepted and move on
18:40:45 <adamw> #agreed 636227 already accepted nth
18:41:04 <jlaska> fix looks to be contained in XFCE code
18:41:15 * jlaska agrees with previously agreed about agreement :)
18:41:24 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=625894
18:41:25 <buggbot> Bug 625894: medium, low, ---, ajax, MODIFIED, kwin freezes when changing related settings in systemsettings while compositing is active
18:42:24 <adamw> seems like a reasonable one to have
18:42:34 <adamw> the fix is to have mesa 7.9 final, which i think has been the plan all along
18:42:42 <adamw> we might want to make sure airlied knows the deadlines for final
18:43:46 <jlaska> "caught airlied on irc, and he said a newer mesa snapshot is in the works for
18:43:49 <jlaska> f14."
18:43:58 <adamw> i'm +1 on this as NTH anyway
18:44:00 <jlaska> adamw: oops, you basically said that already
18:44:03 <adamw> it's a good thing to fix
18:44:18 <adamw> certainly something people could hit prior to updating or in live
18:44:45 <adamw> (which is one of the main nth principles)
18:45:11 <jlaska> as long as that updated mesa goes through bodhi for testing, sure
18:45:28 <adamw> it has to
18:45:32 <adamw> nth doesn't let you circumvent testing
18:46:02 <adamw> (for final anyway, heh)
18:46:03 <jlaska> cool, that was an outstanding question I posted on your NTH thread this morning
18:46:14 <adamw> for final i don't think we allow side packages
18:46:15 <jlaska> alright, NTH+1
18:46:22 <adamw> because then the published repos wouldn't match the images
18:46:32 <adamw> ok
18:46:48 <adamw> #agreed 625894 acceptednth
18:46:52 <jlaska> adamw: right, that was part of my q ... we can iron that out on the list
18:46:57 <Oxf13> no side packages for final.
18:47:17 <adamw> right
18:47:29 <adamw> last one...
18:47:30 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=596557
18:47:31 <buggbot> Bug 596557: high, low, ---, ajax, NEW, KMS initialization breaks display [8086:0046]
18:47:36 <adamw> this is my own little bugbear
18:47:48 <adamw> my shiny laptop utterly fails to work with its Intel graphics adapter
18:48:02 <adamw> the symptom is same as that Dell bug from earlier and James' bug - just hangs at KMS transition
18:48:12 <Oxf13> there is a new intel driver coming, by reading of the libdrm update ticket
18:48:18 <adamw> fix wouldn't be in there
18:48:23 <adamw> there is a fix, it's in kernel and it's very new
18:48:23 <Oxf13> ok
18:48:32 <adamw> from matt barnes upstream
18:48:40 <notting> jesse barnes?
18:48:44 <adamw> erf, yes :)
18:48:45 <jlaska> I'd almost rather consider this for blocker?
18:48:49 <adamw> well
18:48:57 <adamw> ajax and kylem were worried about taking this kind of fix late in cycle
18:48:58 <adamw> ajax: right?
18:49:02 <Oxf13> very new change in the kernel on a fairly popular driver?  WHATCOULDGOWRONG
18:49:04 <jlaska> that's my worry too
18:49:10 <adamw> apparently the area in question is pretty sensitive and fixes can break other shit
18:49:17 <Oxf13> even better!
18:49:21 <jlaska> I'm not 100% comfortable with this riding along
18:49:24 <adamw> this is this shiny new intel thing called edp which apparently basically a nightmare
18:49:37 <adamw> yeah, given ajax/kyle's feedback i'm probably going to un-propose this
18:49:43 <ajax> adamw: to the extent that it's edp-only, meh
18:49:45 <adamw> it seems safer to push it, if anything, post-release with careful testing
18:49:51 <jlaska> adamw: right
18:50:02 <ajax> i haven't looked at what the impact is on non-edp displays.  i suspect it's low, in which case...
18:50:05 <adamw> just a shame it makes the vaio z doa, but meh
18:50:28 <ajax> displayport in general is still a bit immature, sadly
18:50:32 <jlaska> adamw: workarounds?
18:50:52 <ajax> turns out if you make link negotiation something that can fail without feedback, it tends to fail!
18:50:53 <Oxf13> -1 NTH
18:50:57 <adamw> jlaska: for this specific system, workaround is to use the nvidia adapter instead
18:51:06 <jlaska> pooh :(
18:51:07 <adamw> jlaska: which involves a BIOS hack
18:51:19 <jlaska> adamw: to disable switched video or something?
18:51:22 <adamw> jlaska: note, adapter, not driver - you can use the nouveau driver
18:51:24 <adamw> jlaska: yes
18:51:29 <jlaska> k
18:51:34 <adamw> i believe if we had this fix it would work without the BIOS hack but i haven't tested yet
18:51:53 <adamw> given everything it's probably a bit late to try and push this stuff in to make the system work nice ootb so i should just un-propose this and we can deal with it post-release
18:52:19 <jlaska> adamw: I agree ... sorry it's your primary laptop :(
18:52:27 <adamw> ajax: i think the three commits i mentioned in the bug are the only ones needed to fix this, but i dunno how they interact with all the other changes on jesse's branch, btw
18:52:39 <adamw> jlaska: well, I can deal with it, i'm just thinking of all the others who have them =)
18:53:02 <jlaska> adamw: for me ... this is blocker or not (NTH doesn't seem right here)
18:53:05 <jlaska> given the scope of changes
18:53:21 <jlaska> if you're concerned about the exposure ... let's bring this up as a blocker
18:53:29 <adamw> i don't think it's quite wide enough to qualify as blocker
18:53:48 <adamw> for its niche it's a pretty popular system but it is only one system, i don't think this exact bug exists in any other system (unless it's what you're hitting, heh)
18:54:25 <Oxf13> I have to step out for lunch, bbiaf
18:54:33 <adamw> Oxf13: this is the last bug
18:54:37 <adamw> we're done after this one
18:54:58 <jlaska> okay votes ...
18:55:01 <jlaska> NTH -1
18:55:44 <adamw> yeah, -1
18:56:02 <adamw> i'll try and work with ajax to get this fixed after release then i can always do a custom spin for Z owners or something
18:56:20 <jlaska> should we add the commonbugs keyword?
18:56:25 <adamw> sure
18:56:48 <jlaska> of course, this adds more work on your plate, since you're probably best to document :(
18:57:12 <brunowolff> I tried to through https://bugzilla.redhat.com/show_bug.cgi?id=637544 on the nice to have list, but might have messed up.
18:57:13 <buggbot> Bug 637544: medium, low, ---, limb, NEW, File conflicts between cernlib and cernlib-g77
18:57:14 <adamw> so the only bug rejected for my NTH process is the one I proposed...noooo, i fail =)
18:57:31 <adamw> brunowolff: nope, you didn't, but we mass-accepted all dependency/conflict issues
18:57:35 <brunowolff> It's a file conflict that isn't picked up in dep resolution.
18:57:40 <jlaska> adamw: please ... that pales in comparison to my rejected blockers today
18:58:01 <adamw> brunowolff: i didn't go through and put the acceptance text in them yet, i'll do it now
18:58:21 <adamw> so, with that, we're through both lists in 3 hours, not too bad
18:58:37 <adamw> #agreed 596557 change too big for final, rejected as nth
18:58:42 <adamw> #topic open floor
18:58:45 <adamw> any other bugs to bring up?
18:59:09 * jlaska has nothing
18:59:15 * adamw either
18:59:26 <jlaska> adamw: thanks for guiding us through NTH
18:59:44 <adamw> thanks for sticking it out
18:59:59 <jlaska> heh, this was much better than last week
19:00:07 <jlaska> good job all around for work outside of this meeting
19:00:14 <jlaska> I have more hair as a result of this
19:01:28 <jlaska> let's call end of meeting in 60 seconds
19:02:23 <adamw> close enough!
19:02:24 <adamw> #endmeeting