[02:32] <NCommander> apw, do you still need to forward the SPARC patches? (it hit the queue, but I didn't get the bounce until I took off for the weekend)
[06:12] <cooloney> ericm, Jaunty 2.6.28 kernel already merged that patch?
[06:12] <cooloney> ericm,  do you know the SHA of the commit?
[06:12] <ericm> cooloney: please check arch/x86/kernel/cpu/intel.c: line 39
[06:13] <ericm> cooloney: seems to be merged via the stable tree
[06:13] <cooloney> ericm, that is OK
[06:14] <ericm> the change is brought up by the fix
[06:14] <cooloney> ericm, we can change the status to Fixed in Release
[06:14] <cooloney> ericm, cool
[06:14] <ericm> cooloney: now your turn ;-)
[06:14] <cooloney> ericm, ok, no problem. 
[06:14] <cooloney> ericm, thanks for taking a look at this
[06:15] <ericm> cooloney: you are welcome, bro
[10:43] <kdub> hello everyone
[12:31] <apw> kdub, hi
[12:39]  * apw pokes apw_
[12:43] <smb> apw, talking to yourself again. :-P
[12:43]  * apw_ waves to cking 
[12:43] <apw> heh yeah ... just got wireless working
[13:43]  * Keybuk tries to figure out TRACE_EVENT
[14:08] <rtg_> amitk, are you accumulating all of the Karmic  ARM patches from the list? 
[14:23] <Keybuk> rtg_: remind me, is there an easy way to build an i386 kernel on an amd64?
[14:24] <rtg_> Keybuk, other then using a chroot? not that I know of.
[14:24] <Keybuk> that's what I thought
[14:26] <Keybuk> let's see if this works
[14:26] <Keybuk> I've rewritten the old sreadahead ftrace-based open() patch
[14:26] <Keybuk> it now uses TRACE_EVENT
[14:26] <Keybuk> I'm hoping it'll be much easier to get upstream like that ;-)
[14:28] <Keybuk> (assuming that the syscall tracer stuff doesn't make it)
[14:30] <Keybuk> ooh, it compiled :D
[14:31] <rtg_> Keybuk, is anyone championing the syscall tracer stuff ?
[14:32] <Keybuk> no idea
[14:32] <rtg_> Keybuk, couldn't get it in Andrew's tree?
[14:33] <Keybuk> who couldn't/
[14:33]  * Keybuk doesn't follow LKML remember
[14:33] <Keybuk> I only have 24 hours in one day
[14:34] <Keybuk> last I heard about the syscall tracer stuff, Ingo had said he though it was the right thing to do
[14:35] <rtg_> Keybuk, he's also another avenue for getting a patch like that accepted.
[14:35] <Keybuk> (the syscall tracer stuff not being my work :p)
[14:35] <rtg_> oh, I thought it was. I get so confused.
[14:36] <Keybuk> :)
[14:36] <Keybuk> in jaunty we have a patch in our kernel tree which adds a trace for the open() syscall using ftrace
[14:36] <Keybuk> that patch doesn't apply in karmic, so I've rewritten it to use TRACE_EVENT
[14:36] <Keybuk> we'll obviously want to include that in our tree if it works
[14:36] <Keybuk> and I'll forward it upstream as well
[14:37] <rtg_> ok
[14:37] <Keybuk> but I'm mindful that there's separate work upstream to provide a generic all-syscall tracer using tracepoints, which would supercede it anyway
[14:37] <rtg_> its probably time to get it into Karmic 'cause whatever happens upstream won't appear (for us) until LL
[14:37] <Keybuk> but at least, by implementing it on top of trace_event, it'll be compatible :P
[14:38] <Keybuk> right, I only wrote it today :)
[14:38] <Keybuk> am doing the test compile now <g>
[14:38] <rtg_> slacker
[14:38] <Keybuk> hah
[14:41] <Keybuk> hmm, didn't quite work
[14:44] <Keybuk> oh, no, I just didn't copy a file over
[14:49] <Keybuk> hmm, no I didn't
[14:55]  * Keybuk is clearly missing some glue
[16:42] <Keybuk> how do I ignore ABI changes again?
[16:43] <Keybuk> oh, I just fix the changelog entry, that's right
[16:44] <rtg_> Keybuk, you can also 'echo 1 > debian/abi/2.6.31*/ignore'
[16:45] <rtg_> rather, 'echo 1 > debian/abi/2.6.31*/ARCH/ignore'
[16:47] <Keybuk> btw, is it me or is the kernel package missing build-deps these days?
[16:47] <Keybuk> neither kernel-wedge nor makedumpfile are in its deps
[16:48] <rtg_> Keybuk, hmm
[16:48] <rtg_> Keybuk, Build-Depends: debhelper (>= 3), module-init-tools, kernel-wedge (>= 2.24ubuntu1), makedumpfile [amd64 i386 lpia], device-tree-compiler [powerpc]
[16:50] <Keybuk> rtg_: ah, but debian/control is an empty file
[16:51] <Keybuk> that's what breaks it
[16:51] <rtg_> debian/rules clean
[16:51] <Keybuk> so deps work from the source but not from git?
[16:51] <Keybuk> rtg_: clean depends on kernel-wedge <g>
[16:51] <rtg_> Keybuk, debian/control is generated
[16:52] <rtg_> Keybuk, the source package has a correct debian/control, but not the bits that are checked out from git
[16:52] <Keybuk> yeah
[16:52] <Keybuk> Could not open /home/scott/co/linux-karmic/debian/linux-image-2.6.31-4-generic/lib/modules/2.6.31-4-generic/modules.alias at debian/tests/check-aliases line 10.
[16:52] <Keybuk> weird
[16:53] <Keybuk> probably an issue with changing the version part way though the build ;)
[16:54] <rtg_> Keybuk, likely. you're better off using an ignore file.
[16:56] <Keybuk> wildo
[16:57] <amitk> rtg_: I am (collecting all the ARM-related patches, that is). They are at git://kernel.ubuntu.com/amitk/ubuntu-fsl-2.6.31.git
[17:01] <rtg_> amitk, shouldn't we have an official topic branch in the Karmic repo?
[17:02] <bjf> rtg_, we are using a topic branch named "arm" in the Jaunty tree
[17:10] <Keybuk> # grep open /sys/kernel/debug/tracing/available_events
[17:10] <Keybuk> ADMIRAL!  THERE BE TRACERS HERE!
[17:10] <Keybuk> \o/
[17:13] <Keybuk> # tail trace
[17:13] <Keybuk>   tail-2176  [001]    58.986011: do_sys_open: "/etc/ld.so.cache" 0 0
[17:13] <Keybuk>   tail-2176  [001]    58.986054: do_sys_open: "/lib/tls/i686/cmov/libc.so.6" 0 260045
[17:13] <Keybuk>   tail-2176  [001]    58.986149: do_sys_open: "/dev/urandom" 0 26776604320
[17:13] <Keybuk> yay
[17:13] <Keybuk> not sure why the junk at the end, admittedly
[17:17] <Keybuk> ah, random mode when opening without O_CREAT of course
[17:20] <Keybuk> rtg_: incoming patch for you
[17:20] <rtg_> Keybuk, cool.
[17:55] <apw> jjohansen, did we decide that we were happy to enable apparmour now, as the ecryptfs issue was already in jaunty and the static IP addy thing there was going to be a work around in the definition
[17:56] <jjohansen> apw: nope, but I think it is worth doing
[17:57] <apw> i think it was a patch for that functonality wasn't it.  we should get that up onto the mailing list for inclusion
[17:57] <jjohansen> apw: yeah, it adds a config option to set a default security module
[17:58] <apw> cool.  so lets get that up soon and i can get it tested in my ppa
[17:59] <jjohansen> apw: okay, I will commit and push
[18:00] <apw> sounds good
[18:37] <jjohansen> apw: request sent
[18:37] <apw> jjohansen, thanks
[18:43] <rtg_> apw, any erason why CONFIG_SSB and CONFIG_B44 shouldn't be common across all arches/flavours?
[18:44] <apw> probabally not ... shall i sort them out as i have been doing that merging?
[18:44] <apw> and i am about to do an AA config option too :)
[18:44] <rtg_> apw, I've already got that committed locally and am build testing.
[18:44] <apw> ahh ok ...
[18:44] <rtg_> the CONFIG_SSB/CONFIG_B44 patch (I mean)
[18:45] <apw> let me know when you have it pushed so i can work from the top of that on the next config thing
[18:45] <apw> they tend to collide like a pig
[18:45] <rtg_> k, about 30 minutes.
[18:45] <rtg_> I'm also getting Keybuk strace patch
[18:45] <rtg_> er, trace event patch
[18:46] <apw> sounds good to me
[18:46] <smb> rtg_, apw Probably the only risk is for bcmwl but jockey can sort that
[18:47] <apw> smb, whats that risk?
[18:47] <rtg_> smb, its already built for the distro arches anyway. so jockey already has to handle it.
[18:47] <apw> oh i see having it turned on you mean
[18:47] <apw> yeah its arm which is mostly the one which isn't common
[18:47] <smb> apw, ssb has the tendency to grab all ssb capable devices (not necessarily only those it has backends for)
[18:48] <apw> ahh i see
[18:48] <smb> apw, So the wl driver wont work until you remove ssb (plus those using it) then modprobe wl and the again all the others
[18:49] <smb> which is the modprobe rule jockey instals
[18:49] <apw> ahh hence when i installel the wl thing i had to reboot to get it to work
[18:49] <smb> or remove b44+ssb then modprobe wl and probe the other like I did 
[18:49] <smb> exactly
[19:21] <rtg_> apw, karmic pushed
[19:32] <rtg_> Keybuk, what would be a good package for an rfkill application? its needed for acpi-support. perhaps wireless-tools ?
[19:36] <Keybuk> yeah something like that
[19:36] <rtg_> Keybuk, so, just drop it in and send a patch to the debian maintainer?
[19:40] <Keybuk> yup
[19:53] <NCommander> apw, you around? (I'm guessing my SPARC config patch never materialized on the mailing list since i don't see it in history)
[19:53] <apw> not seen it no
[19:53] <apw> if you want to send it again and cc: me then i can follow up on it
[19:53] <NCommander> apw, *sigh*, ok, I have a copy here
[19:54] <apw> these things happen
[19:54] <apw> i assume its not huge?
[19:54] <NCommander> apw, not too big
[19:55] <NCommander> apw, forwarded. If it fails to apply, then we've got a problem; my home router has failed, and I can't access my SPARC box remotely (and unless my super can restart the router which is a longshot), I probably won't be able to fix the problem until I return to Rochester in ~3 weeks
[19:56] <apw> lets hope it applies
[19:57] <NCommander> apw, yeah .... I can try working on faure if it doesn't, but I obviously won't be able to test the results :-/
[19:57] <NCommander> O_O;;;;  http://news.slashdot.org/story/09/07/20/1643251/Microsoft-Releases-Linux-Device-Drivers-As-GPL?art_pos=4
[19:57] <apw> well sparc wasn't building last i looked 
[19:57]  * NCommander feels its a very very cold day in hell ...
[19:58] <apw> its an odd move, lets hope its the open move we would want it to be
[19:59] <NCommander> Indeed
[19:59] <NCommander> But still, Microsoft committing kernel patches ...
[19:59] <apw> i like the chosen tags
[19:59] <NCommander> Next thing you'll know, Apple is going to dump Darwin and move to a LInux base
[20:00] <apw> heh ... that really would imply flying pigs
[20:03] <apw> NCommander, you are in luck it applied
[20:04] <NCommander> \ooooooooo/!
[20:04] <NCommander> That makes me feel better
[20:04] <apw> as it only can affect the ports its pretty safe
[20:04] <apw> (for me)
[20:04] <NCommander> My issue w.r.t. to the new layout of debian/config is one config change breaks all other pending config patches
[20:04] <NCommander> But on the flip side, its nicer to see what is common to all architectures ...
[20:04] <apw> yes and no, not as much as you might think
[20:04] <apw> your change is an issue as its a big mother
[20:05] <apw> and changes a lot of the file
[20:05]  * NCommander notes the ports configs are very very unhappy in general as it stands
[20:05] <NCommander> Well, until now
[20:05] <apw> but there was an apparmor related changed between your change being diffed and applied by me
[20:05] <apw> and they didn't collide
[20:05] <NCommander> Thats a nice warm fuzzy feeling
[20:06] <apw> the ones where you do what you did there, take an arch from BUST to WORKING
[20:06] <apw> is going to run that risk, but generally we change one option at a time and the collisions are managable
[20:06] <apw> i am also sure this isn't the last improvement to config management in my lifetime either
[20:07] <NCommander> Well, it just needed one big change to make everything happy
[20:07] <NCommander> I'm kinda wondering how the configs got this broken though, I thought I fixed all the -ports configs in the jaunty cycle :-/
[20:09] <apw> cannot say, perhaps the wrong ones got pulled to karmic when they merged into the kernel package not sure
[20:14] <NCommander> possibly
[20:14] <NCommander> Oh well, fixed now
[20:15] <apw> heres hoping ... 
[20:45] <manjo> dinh, did u get a chance to repond to amits question regarding the USB patch ? 
[20:59] <rtg_> apw, I figured out where NCommander's patch went. I'd forgotten to moderate the list this morning.
[21:03] <apw> rtg_, ahh did wonder ... it looked benign to us so i have applied it
[21:07]  * NCommander doesn't understand why he keeps hitting the moderation queue
[21:07] <NCommander> I'm subscribed, and @ubuntu.com addresses should be whitelisted
[21:07] <apw> maybe the size limit is very small
[21:10] <rtg_> apw, 40k
[21:43] <dinh> manjo: I responded to amitk's email with a condensed patch that only fixes USB...did you not see it?
[21:43] <manjo> dinh, ah I must have missed it 
[21:43] <manjo> dinh, thanks for the update sir
[21:44] <dinh> sure thang