[07:47]  * smb shuffles in
[07:54]  * apw waves to smb
[07:54]  * smb waves back to apw
[08:17] <apw> ogasawara, about ?
[10:04] <apw> ogasawara, ok then ... i've fixed up the lack of attribution of the rebase to 3.0 and pushed on an abi bump so it'll build
[12:35] <kees> apw: okay, so, the pending/released flipflop we have is due to running certain scripts on our end in the wrong order. basically we need to do gitscan, then usn-mismatch, then the usn-publication-sync. can you do a quick gitscan and I'll merge and sync correctly today?
[12:36] <kees> if we do the usn-pub-sync first it thinks the usn db shows a given cve as being published and closes it.
[13:05] <ogasawara> apw: cool, thanks for doing the rebase
[13:05] <apw> ogasawara, i didn't re
[13:05] <apw> ogasawara, i didn't rebase ... you did
[13:06] <apw> kees, i think now that the 0711 has a version for it and its released i won't argue with the usn
[13:06] <ogasawara> apw: hrm, I hadn't done the actual rebase to 3.0 final
[13:06] <ogasawara> apw: I was gonna do it first thing this morning, eg now
[13:06] <ogasawara> apw: maybe tgardner did it?
[13:07] <kees> apw: true, but after making the usn-publisher not change versions, we ended up in a kind of goofy situation. perhaps I can further improve it to ignore versions greater than the USN's package version
[13:07] <apw> the committer was you i thought ... and on rebase normally the committer becomes the rebase-er i thought
[13:07] <apw> so ... likely was tim anyhow but its looking ok
[13:08] <apw> ogasawara, i'd like to quickly test with overlayfs and push that in before it gets uploaded if that ok with you
[13:08] <ogasawara> apw: works for me
[13:08] <ogasawara> apw: I've got some more modular config review changes to push too
[13:08] <apw> ogasawara, go ahead and push them whenever
[13:10] <ogasawara> apw: pushed
[13:10] <apw> ogasawara, i have built kernels with overlayfs in, if that boots in the livecd i'll push it and then test aufs
[13:10] <ogasawara> cool
[13:11] <apw> i have kernels with and without
[13:11]  * apw shouts at his download link ... get on with it i need that CD image now
[13:12] <apw> kees, ahh i see ... if the version doesn't match my version i will fix ti and move it pending
[13:12] <apw> kees, but if its matching the version it would be, even if its only in -proposed then i won't touch it
[13:12] <apw> as i actually can't tell and assume you do any pending -> something transitions
[13:14]  * kees nods
[13:29] <tgardner> ogasawara, does it seem like a good day to you for an upload ?
[13:29] <ogasawara> tgardner: yep, just waiting for apw to finish up with testing some overlayfs patches he wants to shove on top
[13:30] <ogasawara> tgardner: I assume it was you who did the 3.0 rebase?  if so, thanks!
[13:30] <tgardner> ogasawara, cool. I pushed the rebase last night so I could try it out on emerald
[13:34] <tgardner> ogasawara, bjf: headed into the office now. can't get in before 0700. biab.
[13:39] <kees> fri kernel upload? brave! :)
[13:40] <apw> kees, na not as much as you'd think as it takes days to build, and does't take effect till meta goes in
[13:40] <apw> kees, so its actually a perfect day to upload
[13:41] <kees> oh, yeah, i guess with an abi bump, that is perfect
[13:41] <apw> yeah
[13:41] <apw> kees, so we have a couple of cves outstanding against hardy, one of which at least is going to be a heap of mess required to backport anything close to something thats workable
[13:42] <apw> whats our policy on that kind of thing, if we decide the risk is very great
[13:47] <kees> which cve is it? if it's not a serious issue, we can choose to ignore it or work around it. it's a case-by-case thing.
[13:48] <apw> kees, the one i am particularly unsure about is the epoll recursion one, which likely is a heap to fix, i've not yet tried but it feels like it may well be... so was interested in the process
[13:48] <kees> i try to be risk adverse, which normally means fixing bugs, but if things are really ugly, not fixing is the safe plan
[13:49] <apw> i'll let you know when i've tried and failed :)
[13:49] <kees> heh
[14:41] <ogasawara> tgardner: you rebuilding oneiric chroots on tyler?
[14:41] <tgardner> ogasawara, yep
[14:42]  * ogasawara goes to hammer on tangerine then
[14:42] <tgardner> ogasawara, they were in an intermediate state, so I thought I'd just rip 'em out and start over
[14:42] <ogasawara> tgardner: works for me
[14:42] <tgardner> ogasawara, didn't think you were on tyler
[14:42] <tgardner> yet
[14:43] <ogasawara> tgardner: nope, only just noticed when I went to kick off a build
[15:12] <ogasawara> wow, we're not in the list of top 5 packages for bugs reported against last week
[15:12] <ogasawara> we must be losing our touch :)
[15:13] <sconklin> ogasawara: I can 'fix' that
[15:13] <ogasawara> heh :)
[15:15] <sconklin> that's actually great to know. I've been worrying about the regressions we did have, but perhaps we're having fewer and tracking those better - so it seems worse than it is
[15:30]  * ogasawara back in 20
[16:24] <ppisati> tgardner: can you take a look at the omap4 build?
[16:25] <ppisati> tgardner: i was told to disable the abi check since this was a handcrafted pkg
[16:25] <ppisati> tgardner: but it seems it was checking there
[16:30] <tgardner> ppisati, yeah, I'm in the middle of figuring it out, but got distracted. I'll get it re-uploaded sometime today.
[16:30] <ppisati> tgardner: k
[16:31] <cking> ogasawara, so is my S3 systemtap script broken for oneiric?
[16:31] <ogasawara> cking: bug 754711 mentions it is, but i've not actually confirmed
[16:31] <ubot2> Launchpad bug 754711 in linux "[Dell Studio XPS 1340] Doesn't enter suspend mode" [High,In progress] https://launchpad.net/bugs/754711
[16:32] <cking> ogasawara, ok - I will look at that in the next 24 hours
[16:32] <ogasawara> cking: no hurry, it can wait till next week
[16:33] <ppisati> tgardner: i think it misses three files
[16:33] <ppisati> tgardner: http://pastebin.ubuntu.com/650086/
[16:36] <sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/809878
[16:36] <ubot2> Ubuntu bug 809878 in linux "Wireless network & graphics card stop working after upgrade to 2.6.38-10" [Undecided,New]
[16:40] <apw> Daviey, did we confirm it was the java update which was the problem in this case ?
[16:45] <bdmurray> bjf: it looks like my kernel-driver- tagging of oops reports was incomplete as I only got those with EIP and not RIP
[16:45] <Daviey> apw: We haven't identified what introduced it yet.
[16:46] <apw> Daviey, ok cause i just heard people blaming it as if it was definatly it
[16:46] <Daviey> apw: blaming "it"?
[16:46] <Daviey> The two obvious candidates are either openjdk or kernel.
[16:46] <apw> Daviey, blaming openjdk change for starting to tickle the existing kernel bug
[16:47] <apw> Daviey, you were going to back that out to confirm i believe
[16:47] <Daviey> apw: Who did you hear?
[16:47] <apw> Daviey, kate just said "we would have caught the issue with openjdk ...."
[16:47] <apw> and i wanted to confirm it was confirmed that it was the openjdk update which was the 'cause'
[16:47] <Daviey> apw: Ah. you are sneeking on the call?
[16:48] <apw> (obviously the kernel bug is real and is the root cause)
[16:48] <apw> not sneaking i was invited
[16:48] <Daviey> apw: Oh sure, didn't mean it like that.
[16:48] <Daviey> apw: I'm not entirely sure it's worth the time investment to discover it.. although sucky.
[16:57] <mfilipe> sforshee, aff, I don't understand that intel bug 
[16:58] <mfilipe> it has 1+ year old and it is a very basic feature 
[16:58] <mfilipe> and the Chris Wilson doesn't say nothing :(
[16:59] <tgardner> ppisati, refetch HEAD for ti-omap4. I think it'll build now, but I'm still gonna upload to the c-k-t PPA first just to make sure.
[16:59] <sforshee> mfilipe, which bug are you talking about?
[17:02] <ogasawara> jjohansen: the talk you gave at ubuntu dev week about bisecting, did that get translated into a wiki by chance?
[17:02] <ogasawara> jjohansen: no worries if not, just wanted to point someone at it for how to bisect.  I can always point them to the classroom logs.
[17:02] <jjohansen> ogasawara: hrmm, no its on the todo
[17:03] <mfilipe> sforshee, https://bugs.freedesktop.org/show_bug.cgi?id=38750
[17:03] <ubot2> Freedesktop bug 38750 in DRM/Intel "[Arrandale] Intel Core i3 External Monitor Wavy Output" [Normal,New]
[17:03] <jjohansen> ogasawara: logs are here https://wiki.ubuntu.com/MeetingLogs/devweek1107/KernelDebugging
[17:04] <ogasawara> jjohansen: thanks
[17:04] <sforshee> mfilipe, ah, that one :)
[17:04] <sforshee> yeah, it's annoying, I think they understand what needs to be done but just haven't done it, not sure why
[17:05] <mfilipe> sforshee, yep, he didn't say nothing yet and has MUCH people want the solution 
[17:46] <apw> ogasawara, ok i've pushed up the overlayfs changes, they seems to build, and boot ok, and i am able to use CDs with overlayfs and aufs2 as their union soln.
[17:47] <ogasawara> apw: awesome, I'll get it prepped for upload then
[17:47] <apw> ogasawara, cool, thanks
[17:59] <ogasawara> apw: did you want your SOB added to the overlayfs patches?  I've gotta mark some patches from the delta review as SAUCE anyways, so I could fix them up while I'm at it
[18:14] <apw> ogasawara, ahh yes i meant to do that
[18:14] <ogasawara> apw: ack, I'll add it and push
[18:14] <apw> good spot thanks
[18:31]  * bjf -> lunch
[18:31]  * cking --> EOD
[18:40] <adam_g> hey all.. anyone from the kernel team have any suggestions on how to handle Bug #799630 and its relatives? 
[18:40] <ubot2> Launchpad bug 799630 in drbd8 "package drbd8-source 2:8.3.7-1ubuntu2.1 failed to install/upgrade: drbd8 kernel module failed to build" [Low,Incomplete] https://launchpad.net/bugs/799630
[18:51] <sforshee> adam_g, why is there a dkms package for drbd at all? The driver has been in mainline for quite some time.
[18:52] <adam_g> sforshee: it merged 2.6.33, so it was out-of-tree in lucid
[18:52] <adam_g> anyone whos back ported a kernel will break its updates
[18:53] <sforshee> adam_g, if you're using a backport kernel is the driver not included?
[18:53] <adam_g> i believe there is a similar issue right now with the lirc IR drivers
[18:54] <adam_g> sforshee: it is, but on updates the dkms module attempts to rebuild itself against the current kernel that includes drbd, so it fails
[18:57] <sforshee> adam_g, I see. Some of the errors look like redefinitions of stuff already defined in the kernel, and I don't understand why drdb is defining them at all.
[18:57] <sforshee> Some of the others look like changes to kernel functions
[18:58] <sforshee> so to fix it someone would have to go to the trouble to make drbd understand the differences between the versions at compile time
[19:00] <adam_g> right
[19:01] <adam_g> thats the question. is that something we are interseted in doing to support back ported kernels? or is there packaging magick we can employ to avoid the issue all together?
[19:04] <pgraner> cnd, ping
[19:04] <cnd> pgraner, hey
[19:04] <pgraner> cnd, remember at UDS you fixed a box for me with the Alps touchpad?
[19:05] <pgraner> cnd, what did you do?
[19:05] <pgraner> cnd, I think I found the machine but was going to confirm to see if you fix is there
[19:06] <cnd> pgraner, IIRC I added an /etc/modprobe.d/ file to tell it to use a specific PS2 proto to talk to the device
[19:06] <cnd> but I'm having trouble recalling the specific issue and why that solved it
[19:07] <cnd> if you need info you'll have to refresh my memory more :)
[19:07] <pgraner> cnd, it was the right click was actually a middle, and a a tap was right mouse click
[19:07] <pgraner> cnd, or something like that
[19:07] <pgraner> cnd, and you had to use the proto=bare
[19:08] <cnd> ok
[19:08] <pgraner> cnd, whats the easiest way to tell if its an alps?
[19:09] <cnd> hmmm
[19:10] <cnd> trying to remember
[19:10] <cnd> it's serial/ps2 so it doesn't have a hid vendor/device id
[19:10] <cnd> but there is some form of id
[19:10] <pgraner> cnd, udevadm?
[19:10] <cnd> I need to look in the kernel code
[19:11] <sforshee> adam_g, I don't know the answer to those questions
[19:12] <sforshee> cnd, I was looking at it the other day. It seems each particular driver just does some magic to try to figure out if it supports a given device
[19:12] <sforshee> I didn't see any universal way to identify a vendor/model
[19:12] <cnd> pgraner, the way the ps2 mouse module works is there's a core piece of code that calls out to all the loaded modules
[19:12] <cnd> and each module tries to identify the device
[19:12] <cnd> there's no standard way of identification
[19:13] <cnd> each manufacturer has their own special ps2 query command to get the version
[19:13] <cnd> and say it's a new device that linux doesn't know about, then it will just show up as a bare ps2 mouse I think
[19:14] <cnd> so the only way to know for sure is to figure it out from the product specs
[19:14] <cnd> and/or other people's bug reports :)
[19:14] <cnd> for alps, chances are that if the trackpad isn't working right, then it's an alps :)
[19:15] <sforshee> cnd, pgraner: If you can get the OEM Windows install on a system it can tell you what kind of device it is too
[19:17] <pgraner> sforshee, cnd, all demsg tells me is that is: i8042: PNP: PS/2 Controller [PNP0303:KBC0,PNO0f13:MSA0] at 0x60,0x64 irq 1,12
[19:18] <cnd> pgraner, if you take out the modprobe.d file so it doesn't lock to the bare proto, it might be recognized as alps
[19:18] <cnd> comment out the modprobe.d file and then rmmod and modprobe psmouse
[19:18] <pgraner> sforshee, cnd, found it: input: AlpsPS/2 ALPS GLidePoint as /devices/platform/i8042/serio1/input/input10
[19:19] <pgraner> sforshee, its on my netbook :(
[19:24]  * jjohansen lunch
[19:27] <cnd> heh
[20:37]  * tgardner --> EOW
[21:10]  * herton --> eow