=== bjf is now known as bjf[afk]
[08:53] <smb> Morning
[09:05] <smb> cking, \o
[09:05]  * cking waves o/
[09:06] <cooloney> smb and cking moring *.eu
[09:06] <smb> Hi cooloney 
[09:09] <ikepanhc> good morning .eu \o/
[09:09] <smb> ikepanhc, morning .asia :)
[09:14] <lag> \o/
[09:15] <abogani2> morning all!
[09:15] <lag> cooloney: Has anyone managed to get HDMI on the Panda working yet?
[09:15] <cooloney> lag: oh, i don't think so.
[09:15] <lag> Despite placing vram=8M omapfb.vram=0:8M on the Kernel cmdline I still get "omapfb omapfb: failed to allocate framebuffer"
[09:16] <cooloney> sebjan told me he has no HDMI device. 
[09:17] <lag> Who were we speaking to the other day?
[09:17] <lag> Was it Rob?
[09:17] <lag> And someone else?
[09:17] <cooloney> i think Nicolas?
[09:17] <lag> Possibly
[09:17] <cooloney> i didn't meet Rob before
[09:17] <lag> What time do they normally turn up?
[09:18] <lifeless> rob who ? :)
[09:18] <cooloney> i think they should be on line soon, but not sure about that
[09:18] <lifeless> <- a Rob
[09:18] <cooloney> lag: why not mail out, please cc me, hehe
[09:18] <lag> cooloney: I don't know anyone's addresses
[09:19] <lag> Can you mail me them?
[09:19] <cooloney> lag: oh, forget that. no problem,
[09:19] <TeTeT> smb: I'll visit our customer this week, hope we get some testing done with your lbm for x201 wwan
[09:20] <cooloney> lag: just wanna confirm, is this bug #592295?
[09:20] <ubot2> Launchpad bug 592295 in linux-ti-omap (Ubuntu) "omapdss DISPC error: SYNC_LOST_DIGIT (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/592295
[09:20] <smb> TeTeT, That would be good. To see whether it is working or not. hard to tell without the hw. :)
[09:21] <lag> Yes
[09:21] <lag> cooloney: It was RobClark and prpplague
[09:21] <lag> Chatting with ogra and I
[09:21] <TeTeT> smb: agreed :)
[09:23] <cooloney> lag: ok, i don't have robclark's email. i will mail to sebjan and nico
[09:24] <lag> Is prpplague == nico?
[09:25] <cooloney> lag: no
[09:26] <cooloney> lag: it should be nedc or sth.
[09:26] <cooloney> hehe
[09:27] <cooloney> lag: and how do you think sebjan's solution in the LP of this bug?
[09:28] <cooloney> lag: it looks like a workaround to me
[09:31] <lag> cooloney: All it does it stops the message from printing out and swapping the console
[09:31] <lag> cooloney: I already did that with a 'static int'
[09:32] <lag> cooloney: Hence, I haven't used sebjan's 'solution'
[09:32] <cooloney> lag: right, and you still don't get anything on you HDMI display. 
[09:32] <cooloney> lag: yeah, understand
[09:32] <lag> Correct
[09:38] <lag> cooloney: I am currently building the very latest ti-omap4 branch
[09:38] <lag> I'll let you know if anything changes regarding this bug
[09:39] <cooloney> lag: thanks man. hehe
[09:41] <lag> No worries 
[10:37] <ogra> lag, it needs to be vram=32M and dont set omapfb.vram at all
[10:39] <ogra> cooloney, prpplague's nick is prpplague ;)
[10:40] <lag> ogra: How did you find that out?
[10:40] <ogra> lag, trial and error :)
[10:40] <ogra> i know we have three output devices enabled in omap4, and i know each needs at least 8M
[10:41] <lag> Well done
[10:41] <cooloney> yeah, so for the HDMI issue, we maybe can fix it in videoram code
[10:44] <lag> What console is it?
[10:45] <lag> ogra: -^
[10:47] <ogra> lag, ??
[10:47] <lag> HDMI still doesn't work for me
[10:47] <ogra> lag, you mean the kernel cmdline ? 
[10:47] <ogra> root=/dev/mmcblk0p2 rootwait ro mem=463M console=ttyO2,115200n8 console=tty0 vram=32M
[10:47] <lag> Are you using a full desktop?
[10:47] <ogra> thats what i used to get screen output
[10:48] <lag> I'll try it
[10:48] <ogra> no, just tty atm and the rootfs is screwed 
[10:48] <lag> That's completely different to mine
[10:48] <lag> I have a working rootfs if you'd like it?
[10:48] <ogra> it should even work without setting conole options
[10:48] <ogra> naj, i'm working on the images anyway 
[10:48] <ogra> i have plenty of rootfses around just not on that SD
[10:50] <lag> ogra: http://paste.ubuntu.com/456301/
[10:51] <ogra> are you using a plain HDMI monitor (no DVI or adapters)
[10:52] <lag> Nope
[10:52] <lag> HDMI -> HDMI
[10:52] <ogra> http://paste.ubuntu.com/456302/
[12:05] <jk-> smb: could you take a look at comment 28 on https://bugs.launchpad.net/oem-priority/+bug/557742 ? looks like a symbol versioning issue between kernel modules & l-b-m
[12:05] <ubot2> Launchpad bug 557742 in linux-backports-modules-2.6.32 (Ubuntu) (and 2 other projects) "Lenovo Thinkpad X201 & T410 & W510 not autoswitching to input mic jack in 10.04 (affects: 9) (dups: 1) (heat: 70)" [Undecided,New]
[12:07] <jk-> the symbol version magic in l-b-m shouldn
[12:08] <jk-> 't be different, right?
=== rsalveti_ is now known as rsalveti
[12:55] <smb> jk-, Let me check. They should not be different
[12:56] <smb> jk-, But with thinkpad's and alsa there is an unsolved problem with thinkpad-acpi providing a mixer and alsa from lbm having different alsa versions
=== cnd` is now known as cnd
[14:07] <tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/94b8f28fa6ffd56ba13b88b6e8d98c7b540b61de-maverick/linux-image-2.6.35-6-server_2.6.35-6.7_amd64.deb
[14:11] <ccheney> tgardner, ok will take a look in a min
[14:12] <tgardner> ccheney, this is the upstream response. I updated the bug
[14:12] <ccheney> cool
[14:15] <ccheney> booting into it now
[14:18] <ccheney> tgardner, its looking good so far
=== lifeless_ is now known as lifeless
[14:49] <tgardner> ccheney, done yet?
[14:49] <ccheney> tgardner, it passed the register image test, so i think its fixed
[14:50] <ccheney> when i tried to run an image it didn't work but i'm still looking into that
[14:50] <tgardner> ccheney, k
[14:50] <ccheney> it passed the full 10 loop test
[14:57] <ccheney> tgardner, works
[14:57] <ccheney> tgardner, just needed to reboot my node apparently
[14:58] <tgardner> ccheney, cool. I'll bug ttx about whether he wants a new kernel image. it'll completely piss off ogasawara.
[14:58] <ccheney> heh ok
[14:58] <ccheney> ttx, ^ :-)
[14:58]  * ttx doesn't want to piss off ogasawara :)
[14:59] <tgardner> ttx, can you live with a day-1 kernel update if she uploads right after A2 freeze islifted?
[14:59] <tgardner> is lifted*
[14:59] <ttx> tgardner: we would need to have a PPA with a kernel to allow some testing of eucalyptus during ISO testing
[15:00] <tgardner> ttx, thas easy enough
[15:00] <ttx> tgardner: I just don't want UEC untested on A2, if the test is: "you will hit that one, just do this to workaround it, then continue your testing" I'm ok with it
[15:00] <tgardner> ttx, ok, then lemme get you a PPA kernel building.
[15:00] <ttx> (also allows to validate the kernel upgrade, fwiw)
[15:01] <ttx> kirkland: does that work for you  ? ^^
[15:10] <cnd> apw, ogasawara: it looks like amd64 ddebs aren't getting published: http://ddebs.ubuntu.com/pool/main/l/linux/
=== sconklin-gone is now known as sconklin
[15:19] <Keybuk> apw: thanks for the init cmdline patch; it works perfectly
[15:20] <Keybuk> tgardner: you remember the iwl3945 problems I was having?
[15:20]  * tgardner notes that apw is on vacation this week
[15:20] <tgardner> Keybuk, sort of
[15:21] <Keybuk> tgardner: seems it's definitely an upstream kernel issue, there's traffic on LKML about others experiencing it
[15:21] <tgardner> Keybuk, 'iwlwifi: cancel scan watchdog in iwl_bg_abort_scan' just went into Linus' tree
[15:22] <tgardner> as well as 'iwlwifi: serialize station management actions'
[15:23] <tgardner> Keybuk, actually, there are a couple of i3945 specific fixes.
[15:24] <Keybuk> yeah the updates pulled in seem to be the ones people have tested and say fixes it for them
[15:24] <tgardner> Keybuk, so, we''ll get 'em as soon as Linus declares -rc4
[15:26] <tgardner> Keybuk, you could always apply just the iwlwifi updates to an -rc3 Maverick kernel to see if it fixes your problems.
[15:28] <Keybuk> yeah will try that
[15:28] <Keybuk> the workaround suggested works for me too (ifconfig wlan0 promisc)
[15:32] <ogra> so with the init comdline patch, do i need to use the vars in a literal way or are they capitalized by default ? 
[15:32] <ogra> i.e. do i have root= as root= available in initramfs scripts ? or do i need to check for ROOT ?
[15:33] <ogra> (i'm assuming the initramfs init has the vars globally available as well as upstart does)
=== manjo` is now known as manjo
[15:35] <Keybuk> ogra: the patch does not affect such things
[15:35] <Keybuk> all the patch changes is that, previously, the kernel would only pass unknown arguments to init (splash, frobmybar, etc.)
[15:36] <ogra> what does it affect then ? i thought the vars get exported to the init environment
[15:36] <Keybuk> with the patch, the kernel now passes all arguments to init, including those it knew what to do with
[15:36] <Keybuk> basically, in the default install, it means that instead of just getting "splash" on its command-line, init now gets "ro quiet splash"
[15:36] <ogra> ah, so i still need to parse the cmdline if i want to look for root= in an initramfs script ? 
[15:36] <Keybuk> no
[15:36] <Keybuk> just look at $root
[15:36] <ogra> ah, sweet 
[15:36] <ogra> thats what i'm looking for 
[15:37] <Keybuk> anything with an = in has always, and is still, placed as an envvar in init's environment
[15:37] <Keybuk> that is unchanged
[15:37] <Keybuk> (indeed, much of the /proc/cmdline parsing in initramfs is entirely pointless for this reason)
[15:37] <ogra> hmm, i thought that depended on an export in the /init script 
[15:37] <Keybuk> nope
[15:37] <ogra> ok, great
[15:37] <Keybuk> the initramfs /init script is largely wrong, it makes a $ROOT by parsing /proc/cmdline
[15:37] <Keybuk> when $root was always there all along
[15:38] <ogra> right, i mistook it and used the same parsing routine in my initramfs scripts
[15:38] <ogra> which apparently is a waste :)
[15:38] <ogra> good to know
[15:39] <ogra> i guess there are a lot of scripts that can drop such routines now ... the framebuffer handling parses /proc/cmdline too iirc
[15:40] <ogra> ogra@osiris:~/Devel/branches/livecd-rootfs/livecd-rootfs-1.125$ grep -r cmdline /usr/share/initramfs-tools/scripts/*|wc -l
[15:40] <ogra> 12
[15:41] <Keybuk> "now" is irrelevant, as I said
[15:41] <Keybuk> the patch doesn't change whether or not you need those routiens
[15:41] <Keybuk> you've *never* really needed them for the = ones
[15:41] <Keybuk> but you do currently need them to parse out keywords
[15:42] <ogra> yeah, but there are a bunch that still parse the = ones 
=== bjf[afk] is now known as bjf
[15:44] <ogra> brltty, bootchart, blacklist and framebuffer definately do
[15:47] <ogra> cnd, its pointelss to aks for imx51 or dove bugs to be confirmed fixed in maverick ... we should rather drop these packages from the archive 
[15:47] <ogra> *ask
[15:49] <amitk> ogra: cnd: I don't see any imx51/dove branches. What packages are being created?
[15:49] <cnd> amitk: ogra is talking about bug 423767
[15:49] <ubot2> Launchpad bug 423767 in linux-fsl-imx51 (Ubuntu Karmic) (and 3 other projects) "please enable rt2800usb and disable rt3070sta in the imx51 kernel (affects: 1) (heat: 26)" [Low,Fix released] https://launchpad.net/bugs/423767
[15:49] <ogra> amitk, no packages, i just got bugmail for an ancient bug where cnd asked to check if its fixed in maverick
[15:50] <cnd> so I'll just close it up as won't fix
[15:50] <ogra> amitk, we dont remove binaries from the archive without someone asking for it, they still idle around in the archive atm
=== bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - June-29 - 17:00 UTC
[15:50] <ogra> cnd, well, might be an SRU thing, not sure
[15:51] <ogra> cnd, though for that specific one its likely something to just close, i doubt anyone will actually put time into it
[15:51] <cnd> ok
[15:51] <cnd> I'm just trying to clear out crufty linux-firmware bugs :)
[15:52] <ogra> yeah, i got that watching -devel :)
[16:06] <ogasawara> tgardner: for the UEC bug, you're already handling pushing the fix to a PPA correct?
[16:06] <ogasawara> tgardner: I'll get the kernel ready for upload and coordinate with the release team for the 0-day upload
[16:07] <tgardner> ogasawara, yep, I'll feed you a pull request presently as well.
[16:07] <ogasawara> tgardner: sweet
[16:08] <tgardner> ogasawara, Changli says Jens Axobe hasn't acked it yet, so I think we'll carry it as an Upstream patch until it gets resolved.
[16:08] <ogasawara> tgardner: ack
[16:11] <ogasawara> cnd: not sure why the amd64 ddebs aren't getting published.  I'm not familiar with what magic is involved but I'm guessing pitti might?
[16:18] <tgardner> ogasawara, its an archive admin issue
[16:19] <ogasawara> tgardner: so pitti would be a good person to nudge
[16:19] <tgardner> ogasawara, indeed, he is always a good person to nudge
[16:21] <ogasawara> cnd: I'll ping him about it in #ubuntu-devel
[16:22] <cnd> ogasawara: thanks!
[16:25] <ogasawara> RAOF: just saw your common bug tag email for X and kernel.  I definitely agree we should converge on a common set of tags.
[16:25] <ogasawara> RAOF: But ideally I'd like to wait to have this conversation when JFo and apw are around (both are on holiday this week).
[16:34] <cking> another day, another BIOS check
[16:41]  * cking reboots
=== kamal-away is now known as kamal
[17:23] <ogasawara> cnd: pitti will check on the ddeb issue tomorrow morning
[17:27] <ogasawara> ok dudes, we've got 3 remaining Alpha2 work items.  I just want to get a status check if they'll be done by thurs or if I should bump them to Alaph3.
[17:28] <ogasawara> jjohansen: "Refresh Xen patchset and get xen version of EC2 kernel working in Maverick".  I assume you're still working that.  Should I bump to A3?
[17:28] <ogasawara> manjo: "blacklist old firewire stack & enable new stack", seems that's still in progress?  Should I bump it to A3?
[17:28] <jjohansen> ogasawara: yeah, I thought I had done that already
[17:28] <ogasawara> jjohansen: oh, if it's done, I can just close it
[17:29] <jjohansen> ogasawara: no, I meant moved to alpha3
[17:29] <jjohansen> when I talked to tim and andy last week
[17:29] <jjohansen> hrmm, must not have saved
[17:29] <ogasawara> jjohansen: hrm, I'll double check it and if it's not moved to A3 I'll move it
[17:31] <ogasawara> cking: "Investigate situation with Intel graphics drivers on EFI".  Think you'll squeeze this in by Thurs or should I bump this to Alpha3?
[17:34] <cking> ogasawara, I'm discussing this with Intel. Still open - I got a response today, I need to follow it up though. Maybe A3 is better
[17:34] <ogasawara> cking: ok cool, I'll move it
[17:34] <jjohansen> ogasawara: oh, I have to thursday for kernel alpha2 items?  I should have it done by then, if so should I mark it DONE and move it back
[17:35] <ogasawara> jjohansen: yah, if you get it done by Thurs, just move it back and mark it DONE.
[17:35] <jjohansen> okay will do
[17:47] <tgardner> ttx, https://bugs.edge.launchpad.net/eucalyptus/+bug/588861/comments/38 (when its done building)
[17:47] <ubot2> Launchpad bug 588861 in linux (Ubuntu Maverick) (and 4 other projects) ""pad block corrupted" error when trying to register an image with 2.6.34 kernel (affects: 1) (heat: 12)" [High,In progress]
[17:48] <ogasawara> tgardner, ttx:  I'm just waiting for armel to finish building so I can get the abi and start the next release.  Will apply the patch and have a kernel ready for the 0-day upload after that.
[17:55] <manjo> ogasawara, I submitted the patch to ubuntu kenel mailing list 
[17:56] <manjo> ogasawara, tgardner supposed to pick it up, and pgraner was going to submit more test results 
[17:56] <ogasawara> manjo: right, but it doesn't look to be packaged and uploaded.  And since we're on the verge of the A2 freeze I assume it'll have to wait till A3.
[17:57] <manjo> ogasawara, ok. tgardner any chance you will pick this one up for A3 ? 
[17:58] <pgraner> manjo: I can't get it working
[17:58] <tgardner> manjo, I've sent Keybuk a review request. Lemme find it.
[17:58] <pgraner> manjo: none of the fw cards I have are detected under maverick, they are on lucidc
[17:59] <Keybuk> tgardner: ah, well nagged
[17:59] <Keybuk> fwiw, I'm maintaining module-init-tools using the new standard bzr model
[17:59] <Keybuk> bzr branch lp:ubuntu/module-init-tools
[17:59] <Keybuk> we don't use Vcs-Bzr for those
[17:59] <pgraner> manjo: I just got a lap top (StinkPad X410) that maverick does see the fw card so I'll test today
[17:59] <tgardner> Keybuk, I use bzr so seldom that its a half day learning curve each time
[18:00] <manjo> pgraner, ok 
[18:00] <Keybuk> tgardner: I would tend to NAK that patch
[18:00] <Keybuk> can you not make acct=1 the default in the nf_conntrack module?
[18:01] <pgraner> manjo: whats the link to the fw testing page again?
[18:01] <tgardner> Keybuk, upstream is gonna make it 0
[18:01] <Keybuk> yes, so we should patch that to be 1 in our kernel if we want that to be the default
[18:02] <tgardner> Keybuk, well, I don't know that we do, but how is that related to firewire ?
[18:02] <Keybuk> tgardner: ? firewire?
[18:02] <Keybuk> I'm looking at your NF_CT_ACCT mail
[18:02] <Keybuk> which is the most recent thing you mailed me to review
[18:02] <tgardner> thats the review request I was referring to
[18:02] <manjo> pgraner, just a sec 
[18:02] <tgardner> Keybuk, hmm, lemme get my shit sorted out
[18:03] <Keybuk> I don't have anything about firewire
[18:04] <tgardner> keybugok, I remember now. I haven't written the firewire stack blacklist patch yet. I was waiting on results from pgraner. the  NF_CT_ACCT patch is a different issue, and may well be moot at this point.
[18:04] <Keybuk> right
[18:04] <manjo> pgraner, https://wiki.ubuntu.com/Kernel/SwitchFirewireStack
[18:04] <Keybuk> firewire is just a matter of switching stacks, no?
[18:05] <tgardner> Keybuk, yes
[18:05] <Keybuk> unblacklist the new one, blacklist the old one
[18:05] <Keybuk> and pick a date that we stop building the old one
[18:06] <manjo> tgardner, won't the patch I sent to ubuntu kernel list work ? it was a bzr patch?
[18:06] <manjo> Keybuk, we will build both ... just black list the old modules 
[18:07] <Keybuk> right, and we should pick a day where we stop building the old one and drop support for it
[18:07] <Keybuk> e.g. after 12.04
[18:07] <manjo> ah
[18:08] <manjo> if we don't see problems in maverick we could drop it altogether in M+1 
[18:09] <Keybuk> not sure whether or not we need udev rules for it
[18:09] <maks_> lol on Ubuntu for having old firwire :P
[18:10] <maks_> Keybuk: you had the tradition to hire the wrong linux-2.6 hackers :)
[18:10] <Keybuk> maks_: I didn't hire any hackers
[18:11] <maks_> well i remeber the big press release when BenC got hired
[18:11] <maks_> and the Ubutntu kernel put on kernel.org
[18:11] <manjo> Keybuk, https://ieee1394.wiki.kernel.org/index.php/Juju_Migration
[18:11] <Keybuk> Ben left before the new firewire stack was even written
[18:11] <maks_> no i had been in the channel when he loled on us switching
[18:11] <maks_> and leaving his rotten code.
[18:12] <Keybuk> manjo: what I mean is that the rules already seem to be in upstream udev
[18:12] <manjo> Keybuk, ack
[18:12] <pgraner> manjo: ok, video works with both dvgrab & kino, will check the sbp2 stuff in a bit
[18:13] <manjo> pgraner, ack... thanks
[18:13] <maks_> the security implications of the old dma stack is fun
[18:13] <maks_> makes it easy to poke anywhere.
[18:14] <Keybuk> which is why we always locked it down to root-only
[18:15] <manjo> maks_, and your point is ? 
[18:16] <maks_> manjo: fun to see that you have an LTS with the old stack
[18:16] <maks_> although your userspace back then already supported juju.
[18:17] <Keybuk> it's always easier to support an older known stack for a long time than a shiny new one
[18:17] <Keybuk> the new one was always there and was a simple config change for anyone to switch for it
[18:17] <manjo> maks_, next LTS will have the new stack ... if that makes you happy
[18:18] <manjo> maks_, like Keybuk said 
[18:44] <cking> manjo, you're back from your travels?!
[18:45] <manjo> cking, yes 
[18:45] <manjo> cking, back and pretty tired 
[18:46] <cking> much appreciate you going on the trip.  I'd like to catch up and get some feedback sometime, but when you're ready
[18:47] <manjo> cking, yep we can mumble tomorrow ? 
[18:48] <cking> manjo, yeah, good plan. I need to go in a mo, so tomorrow is good for me.
=== maco2 is now known as maco
=== emma_ is now known as emma
[19:14] <jcastro> I bought a new laptop and the nic only works in maverick kernels, I suspect at some point the driver goes into lbm, when we do LTS point releases do those drivers end up updated on the media?
[19:15] <tgardner> jcastro, compat-wireless in LBM shod be the solution. Those drivers will not show up i a point release
[19:16] <jcastro> ok so I suppose that means this laptop won't be kickstartable for me with lucid
[19:16] <jcastro> are normal NIC drivers in compat-wireless too?
[19:16] <tgardner> jcastro, there are a few, but its mostly wireless drivers
[19:22]  * tgardner lunches
[19:42] <jjohansen> -> Lunch
=== mjg59` is now known as mjg59
[20:51]  * ogasawara lunch
=== soren_ is now known as soren
[22:16] <Frode_Haugsgjerd> hey, i have an issue with xchi on my brand new hp 8540p, when i connect my nokia n900, syslog quicly grows with messages like this: "WARN urb submitted to disabled ep" 
[22:17] <Frode_Haugsgjerd> i have of course searched the fine web, but only found the kernel code that emits this message
[22:26] <Frode_Haugsgjerd> ok so i guess my question is, has anyone heard of this before?
[22:41] <kees> ogasawara: will you be able to revert f1befe71fa7a79ab733011b045639d8d809924ad for the next kernel (bug 597075)?
[22:41] <ubot2> Launchpad bug 597075 in linux (Ubuntu) (and 1 other project) "2.6.35 hangs at boot due to regression in i915 or intel_agp (affects: 2) (heat: 12)" [High,Triaged] https://launchpad.net/bugs/597075
[22:45] <ogasawara> kees: the only fear I have with reverting is it could then cause regressions for others
[22:46] <ogasawara> kees: has there been any progress with upstream?
[22:46] <ogasawara> kees: I saw the comments to the upstream bug report, but didn't seemed to present a solution, just more questions
[22:46] <kees> ogasawara: they have no solution.
[22:46] <kees> ogasawara: and reverting it would be the same as lucid's behavior.
[23:04] <ogasawara> kees: I'm still debating :)  your point is valid that it does bring us back to lucid's behavior and you can at least boot.
[23:05] <ogasawara> kees: I've got a 0-day Alpha2 kernel upload that's gonna take precedent and won't contain the reverted patch
[23:05] <ogasawara> kees: so at best I'd like to maybe wait till we rebase to -rc4 and then revert if there's no better solution by then
[23:19] <kees> okay
=== sconklin is now known as sconklin-gone