[02:31] <michaelh1> Hi there.  Natty 2.6.38-8 panics on me about once a day.  Where should I report this?
[02:32] <RAOF> Launchpad.
[02:32] <michaelh1> Yes, but where abouts?
[02:32] <RAOF> And, I guess you've reported it here, too.  Does apport not pop up suggesting you file a bug?
[02:33] <michaelh1> No, the machine dies and there's no apport dialog when it comes back up.
[02:33] <RAOF> “ubuntu-bug linux” is the requisite incantation for bug reporting if apport's not catching it.
[02:33] <michaelh1> Ah, ta.  Running now...
[02:34] <michaelh1> I have a photo of the panic backtrace.  How can I attach it?
[02:35] <michaelh1> Ah, I see there's a browser window opening up...
[02:35] <RAOF> Once the bug report is on launchpad, attach the file :)
[02:36] <jk-> now we just need to "close the loop" and get LP to fix the bug
[02:38] <RAOF> I'm all for creating a sentient bug-fixing launchpad.
[02:38] <RAOF> Chop chop!
[02:39] <lifeless> but does the strong anthropic principle apply?
[02:40] <RAOF> That a sentient bug-fixing launchpad would only exist in a world filled with bugs?
[02:42] <jk-> sentient? I propose RAOF gets the job of holding his hand over the big red killswitch in case LP goes all skynet on us
[02:43] <RAOF> Any sufficiently advanced AI malevolent enough to require use of the killswitch is malevolent enough to remove the ability to press the killswitch :)
[02:43] <jk-> your job with the killswitch includes monitoring the killswitch
[02:44] <jk-> :D
[06:56]  * apw yawns
[06:57] <RAOF> Want some more bees to gargle? :)
[07:00] <apw> i like my women like i like my coffee covered in bees
[07:02] <apw> RAOF, hows things looking for release from your point of view
[07:02] <RAOF> By and large, pretty good.
[07:03] <apw> there are some bugs out there, even some nasty ones, but not a huge heap of them
[07:03] <RAOF> There are some nouveau crazies, but for some reason laptop manufacturers like to put totally insane bioses on nvidia systems.
[07:03] <RAOF> There's one big bug involving compiz freezing that I thought we'd fixed on Friday, but sadly not.
[07:03] <apw> that is so helpful of them, you'd think that the nvidia would specify the bios really
[07:03] <RAOF> It might be in the kernel (missing vblank events) or it might be in libx11.
[07:04] <apw> hrm
[07:04] <apw> which grphics?  or is it all of them?
[07:04] <RAOF> intel!
[07:04] <RAOF> No one uses it.  It's pretty obscure :)
[07:04] <apw> yeah minor corner case
[07:05]  * apw shakes head
[07:05] <RAOF> Oh, and btrfs remains molasses-slow, but that's hardly news :/
[07:06] <apw> yeah, that one has yet to live up to its billing, though that is the common case of all new filesystems
[07:06] <apw> they are really quick until the data loss bugs are gone
[07:06] <RAOF> Heh.
[07:06] <apw> ext4 and ext3 went trhough being as fast as anything, but your data was on a knife edge
[07:07] <RAOF> Which is a pity, because btrfs has some all sorts of awesome in it.  Once it's fast enough for regular use, I guess.
[07:08] <apw> yeah, it has a nice model if it can ever be made performant
[07:08] <apw> great for rollback and the like
[07:09] <RAOF> Hot data migration for ssds would be nice, too.
[07:09] <RAOF> And nice schroots and such.
[07:09] <apw> so there doesn't seem to be anything for i915 at all in either 2.6.38.3 (which is pending for the first SRU) or in the stable queue
[07:10] <RAOF> Yeah, I don't think there's anything anywhere for it.  I'm not yet sure it *is* an i915 bug.
[07:38] <apw> today is our last window for an upload really, and right now there is nothing pending which warrents the risk of actually doing one as far as i can see
[07:38] <apw> RAOF, ^^
[07:45] <RAOF> apw: I concur.
[08:48]  * smb waves to apw
[08:48] <apw> smb, moin, hows you
[08:48] <apw> smb, do we still use the cve bzr thingy?
[08:48] <smb> apw, Good, just slow to get to work. :)
[08:49]  * amitk read that as CVS bzr thingy and shivered...
[08:49] <smb> apw, I guess we use the bzr branch but more on a manual approach
[08:49] <apw> amitk, hehe
[08:49] <apw> smb, ok so will update the branch then
[08:50] <smb> apw, I must admit I have not done much cve lately. Too much time spent on other things
[08:50] <apw> me also, just was updating the awsome tracker with some new cves was all
[08:51] <smb> *sigh* there is always new
[09:05] <smb> The cking is back. :) Was it next week when you are on vacation?
[09:05] <cking> smb, no vacation as yet
[09:06] <smb> Ah ok, saw it somewhere and was for some reason believing it would be this week
[09:07] <smb> As this Fridays is a Good Friday. :-P
[09:08] <cking> smb, yep, may take wednesday off - electrician is doing the final wiring 
[09:09] <smb> cking, Good idea. Not good to have computers running while someone pokes around with a screwdriver
[09:09] <smb> So You can move around Easter?
[09:10] <cking> still got to decorate the office - got to wait 5 weeks for the plaster to dry before I can apply paint
[09:12] <smb> 5 weeks!? That is so close to torture... :-P
[09:19] <cking> smb, well it's dry-ish now, but if put modern paints on it now it the pain will trap in moisture forever
[09:21] <smb> cking, Understandable, though it feels very hard to have an office place that is connected and all but you have to wait for some plaster to dry.
[10:36] <Daviey> apw, Can you confirm that bug 747090 fix, will land in the next kernel upload?
[10:36] <ubot2> Launchpad bug 747090 in linux "wrong return address sometimes pushed for INT in kvm (not qemu)" [High,Fix committed] https://launchpad.net/bugs/747090
[10:36] <apw> yes that fix is committed and will be in the first SRU upload
[10:37] <apw> Daviey, ^^
[10:39] <Daviey> apw, ah, super - thanks!
[10:53] <eagles0513875> what about bug 762496 what will happen if compiling the vanilla kernel fixes the issue
[10:53] <ubot2> Launchpad bug 762496 in linux "atheros wifi cards cause kernel panic when connecting to wpa2 secured wifi networks" [Undecided,New] https://launchpad.net/bugs/762496
[11:12] <apw> eagles0513875, if 2.6.38.3 fixes your issue then that is going to be released as the first sru for the kernel
[11:12] <apw> which is normally 1-2 weeks after release
[11:12] <eagles0513875> ok there were some patches released to fix that issue for 2.6.38.3 
[11:12] <apw> eagles0513875, and have you tested that they fix your issue?
[11:13] <eagles0513875> working on it as we speak
[11:13] <apw> well thats good feedback if you can indicate which patches fixed the problem we can tag them and the bug will close out automatically when the SRU releases
[11:14] <eagles0513875> apw: any chance to get it in before the first sru release 
[11:14] <eagles0513875> as there are going to be tons of disgruntled people
[11:14] <apw> very unlikely now, if this was raised a week ago before the freeze we might have gotten it in, though the fix was only available friday i believe
[11:15] <eagles0513875> ya i was talking to someone about that friday as it has been plaguing me big time
[11:15] <apw> that is the problem with people waiting till the last minute to test, its all too late to do anything about
[11:16] <eagles0513875> no chance to file a freeze exception
[11:16] <apw> unless someone in the kernel team happens to have the h/w we simply don't find out
[11:16] <apw> the problem is timing, a kernel rebuild takes close to 24 hours, and it has to be done before 9am tommorrow
[11:17] <apw> which is basically impossible now
[11:17] <eagles0513875> ahh
[11:17] <eagles0513875> 24 hrs O_o
[11:17] <eagles0513875> im suprised canonical doesnt have a dedicated high end machine to cut down the kernel packaging and compilation time
[11:17] <apw> and then we have to respin the installer etc
[11:18] <apw> eagles0513875, there are no such things as high end armel boxes
[11:18] <apw> which is why our freezes are loudly advertised, and pretty much hard
[11:18] <apw> and why testing early is sooo important
[11:19] <eagles0513875> then in that case whats the earliest one can get in on upgrading to the next dev release
[11:19] <eagles0513875> that isnt part of the canonical staff
[11:19] <apw> eagles0513875, from the moment the archive opens,
[11:19] <eagles0513875> which is usually how long after
[11:19] <eagles0513875> release
[11:19] <apw> there is no special treatment for canonical staff
[11:19] <apw> usually less than a week
[11:19] <apw> but even testing the alphas would be good
[11:20] <apw> those appear very early in the cycle
[11:20] <eagles0513875> ya the problem for me is time atm :( 
[11:24] <eagles0513875> apw: mind if i pm ya a sec
[11:24] <apw> eagles0513875, yep, a problem for a lot of people, but it means you'll likely have to wait a couple of weeks longer than the rest to upgrade
[11:24] <apw> eagles0513875, ok
[11:24] <eagles0513875> im already on natty i just cant use the wifi at home
[11:37] <apw> eagles0513875, you might want to test the kernel which is in the pre-proposed archive
[11:37] <apw> https://launchpad.net/~kernel-ppa/+archive/pre-proposed
[11:37] <eagles0513875> i was gonna recompile as there are some default things which on a netbook i dont need 
[11:37] <apw> that should be similar to the SRU kernel and contain the .3 fixes
[11:38] <eagles0513875> :) will give that a shot. is it possible if that has the fixes to get that pushed today before release
[11:38] <apw> that is simply built from the tip of our tree, that is what is committed for the next upload
[11:39] <apw> i will discuss it, but i suspect we are unlikely to be uploading before release now
[11:39] <eagles0513875> the biggest prevention you have here is disgruntled users
[11:39] <eagles0513875> upon release
[11:40] <apw> eagles0513875, i have to balance risk, known breakage for you and the (relativly) small number of atheros users against the risk of making any change which can affect all other users
[11:40] <eagles0513875> true
[11:40] <apw> as esentially any change now invalidates all of the testing we have done to now
[11:41] <apw> now in theory its low risk, but ... non-zero and we have been bitten by just recompiling breaking things
[11:41] <apw> i will try and get a specific kernel with those atheros patches today for you to test at least
[11:42] <eagles0513875> im trying the preproposed as you mentioned above if that containes the 38.3 fixes
[11:42] <eagles0513875> i dont think kde 4.6 is ready for prime time though im getting crashes left right and center
[11:44] <apw> you are 64 bit yes ?
[11:44] <eagles0513875> all im noticing right now somethign is seriously up with networking stack all of a sudden here :-/
[11:44] <eagles0513875> yep
[11:44] <eagles0513875> maverick 64bit is rock solid
[11:44] <eagles0513875> is the pre proposed up or down?
[11:44] <eagles0513875> i ran apt-get update and im getting an error no address associated with hostename
[11:48] <apw> eagles0513875, was there when i looked just now
[11:49] <eagles0513875> ok let me reboot im having some connectivity issues
[11:58] <eagles0513875> now for the moment of testing truth
[11:58] <eagles0513875> apw: what i did find funny in testing 
[11:58] <eagles0513875> if i leave my wired network plugged in and then connect to wpa2 connection it doesnt kernel panic
[12:00] <apw> eagles0513875, odd indeed
[12:00] <eagles0513875> now knetworkmanager is crashing non stop for me
[12:00] <eagles0513875> woohoo
[12:05] <eagles0513875> apw: ill keep working on this later im off for lunch for now
[12:44] <apw> eagles0513875, can you test http://people.canonical.com/~apw/lp762496-natty/ and report back
[12:44]  * apw drops for a bit
[12:58] <M_gerorge> hi.. i have written code to copy data from kernel to user space.. But its not showin the required output.. :(  code is on http://paste.ubuntu.com/595486/       ..... please suggest..
[13:08] <fairuz> M_gerorge: hmm.. to copy from or to user space you should use write and read function
[13:09] <fairuz> module_init will only be called once when you insert the module using insmod
[13:10] <M_gerorge> fairuz: ok.. but i have written these copy_[to/from]_user functions in read and write but they are still not called..
[13:10] <fairuz> you have to have a write and read function in kernel space too!
[13:10] <fairuz> it's not magic :D
[13:11] <M_gerorge> fairuz: :D.... but copy_to/from_user are inbuilt or not?
[13:11] <M_gerorge> :p
[13:12] <fairuz> M_gerorge: Yes, but how you will call it from user space?
[13:12] <M_gerorge> fairuz: yes.. this is the basic which i am not getting. can you please tell me how can i explore about this more?
[13:13] <fairuz> M_gerorge: For me, a simple module needs to have at least 4 functions
[13:13] <fairuz> init, exit, write and read
[13:14] <fairuz> hmm and also, open and release functions
[13:14] <M_gerorge> fairuz:yes..  as i am running the scull driver example it is simply loaded and exited.. but how can i use the functions scull_read and scull_write?
[13:14] <fairuz> You need to have a device nod
[13:15] <M_gerorge> fairuz: is this the dev_t *dev?
[13:15] <fairuz> M_gerorge: no.. something like /dev/mydevice
[13:15] <fairuz> it's a file that you create with mknod
[13:16] <M_gerorge> fairuz: ok .. i can do this.. then what to do next?..
[13:16] <M_gerorge> :P
[13:16] <fairuz> hmm.. wait, I give a link
[13:16] <fairuz> http://www.freesoftwaremagazine.com/articles/drivers_linux?page=0%2C0
[13:17] <fairuz> follow the tutorial here and come back if you encounter some problems :D
[13:18] <M_gerorge> fairuz: thanks a lot and i used this tutorial also. but not get my answer.. :(
[13:18] <M_gerorge> fairuz: in this the dev/memory is created
[13:18] <M_gerorge> but how to use the memory_read and memory_write function?.. :(
[13:19] <fairuz> Ok, I'll explain. (but remember that I'm not an expert myself and maybe it's a bit off course) :D
[13:20] <M_gerorge> fairuz: it wil be my pleasure to be taught by you..:)
[13:20] <fairuz> M_gerorge: Are you sure you followed the tutorial? I dont see any major number in your code
[13:21] <M_gerorge> fairuz: yes.. actually thats is the normal code i wrote myself to use copy_functions
[13:21] <M_gerorge> fairuz: can i paste the other codes? :p
[13:22] <fairuz> to pastebin, sure :D
[13:22] <M_gerorge> thanks.. let me do this
[13:24] <M_gerorge> fairuz: please see http://paste.ubuntu.com/595492/
[13:25] <fairuz> M_gerorge: if you are new to device drivers, I afraid that's maybe a little bit complicated?
[13:25] <M_gerorge> fairuz: i will try my best to understand
[13:26] <fairuz> M_gerorge: Can you follow the memory device driver tutorial I gave you?
[13:27] <M_gerorge> fairuz: yes.. 
[13:27] <fairuz> Come back to me if there are something that you don't understand
[13:30] <M_gerorge> fairuz: i read it and understood it completely.. :p.. but it doesnt gave how to access the memory_read and memory_write functions.. :(..  while doing "echo -n abcdef >/dev/memory" and "cat...." these commands doesn't use these memory_read and write too... :(
[13:30] <fairuz> of course it does :D
[13:31] <fairuz> when you create a module, you associated a major number to it
[13:31] <fairuz> let say 70
[13:31] <M_gerorge> yes
[13:31] <fairuz> And apart from that
[13:31] <M_gerorge> yes
[13:31] <fairuz> you need to create a device nod using the same major number
[13:31] <M_gerorge> yes
[13:31] <fairuz> let say /dev/mydev
[13:32] <fairuz> so in your module, normally you specify the file operations struct
[13:32] <M_gerorge> yes
[13:32] <fairuz> e.g struct file_operations pmnc_fops = {
[13:32] <fairuz> 	write:  pmnc_write,
[13:32] <fairuz> 	open:	pmnc_open,
[13:32] <fairuz> 	release:pmnc_release,
[13:32] <fairuz> 	unlocked_ioctl: device_ioctl
[13:32] <fairuz> };
[13:32] <fairuz> so from user space
[13:33] <fairuz> when you write to the device nod, it's like you call the write function in the module
[13:33] <fairuz> e.g when you do echo "123" > /dev/mydev
[13:33] <M_gerorge> fairuz: ok.... :p
[13:34] <fairuz> in the backend, it will call the write function of your module with "123"'s pointer as it's buffer
[13:34] <M_gerorge> ok..
[13:34] <M_gerorge> yes
[13:34] <M_gerorge> and same with the "
[13:35] <M_gerorge> "cat ..." it calls the read function
[13:35] <M_gerorge> :P
[13:35] <fairuz> for read, it's the same principals
[13:35] <fairuz> yes
[13:35] <fairuz> that is in command line
[13:35] <fairuz> but if you want to use it user space program
[13:35] <M_gerorge> yes
[13:35] <fairuz> you can open /dev/mydev like normal files
[13:36] <fairuz> that use fread and fwrite functions
[13:36] <M_gerorge> ok...
[13:36] <M_gerorge> fairuz: now one issue i found that i added printk lines for debugging.. and they dont get printed.. 
[13:37] <M_gerorge> so i concluded that these functions are not called.. :P
[13:37] <fairuz> if you do dmesg | tail
[13:37] <M_gerorge> yes
[13:37] <fairuz> you will found them :D
[13:37] <M_gerorge> means in "/var/log/message"
[13:37] <M_gerorge> ?
[13:37] <fairuz> or tail /var/log/messages
[13:38] <M_gerorge> yes.. i dint find them in that.. :p
[13:38] <M_gerorge> but i may be wrong.. i will check once more
[13:38] <M_gerorge> fairuz: let me check once more this
[13:38] <M_gerorge> printk commands
[13:38] <fairuz> M_gerorge: ok
[13:38] <fairuz> use pr_info instead
[13:39] <fairuz> :D
[13:39] <M_gerorge> ok. thanks.. :).. let me try
[13:39] <M_gerorge> :P
[13:48] <M_gerorge> fairuz: it's called and shown too..
[13:49] <fairuz> nice
[13:49] <M_gerorge> fairuz: thanks a lot for giving me your precious time... :p
[13:50] <M_gerorge> fairuz: will come back to you if i will have more problems.. :D..
[13:52] <M_gerorge> fairuz: good bye...
[15:22] <JFo> rebooting for updates... brb
[17:03] <tgardner> ogra_, linux-meta-ti-omap4 2.6.38.1208.7 accepted
[17:03] <ogra_> tgardner, awesome !
[17:41] <JFo> there may be an issue with either apport or ubuntu-but (I assume this is apport too?) as shown in bug 764341 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/764341
[17:41] <ubot2> Launchpad bug 764341 in linux "WARNING: at /build/buildd/linux-2.6.38/net/sched/sch_generic.c:256 dev_watchdog+0x213/0x220()" [Medium,Incomplete]
[17:41] <ubot2> Launchpad bug 764341 in linux "WARNING: at /build/buildd/linux-2.6.38/net/sched/sch_generic.c:256 dev_watchdog+0x213/0x220()" [Medium,Incomplete] https://launchpad.net/bugs/764341
[17:41] <JFo> oh good, the bot is back :)
[17:45] <cking> who feeds and tends the bot?
[17:49] <charlie-tca> nobody, apparently. Thus it goes off on its own? ;-)
[18:08] <JFo> tgardner, ever seen this? bug 764273
[18:08] <ubot2> Launchpad bug 764273 in linux "WARNING: at /build/buildd/linux-2.6.38/ubuntu/aufs/plink.c:450 au_plink_put 0x4c/0xa0 aufs " [Undecided,New] https://launchpad.net/bugs/764273
[18:09] <tgardner> JFo, I'm wondering why aufs is even loaded?
[18:10] <JFo> *shrug
[18:10] <JFo> unless he needs it for whatever he is building (mozilla maintainer)
[18:11] <JFo> I confess I know next to nothing about aufs
[18:11] <JFo> tgardner,: <JFo> micahg, that plink error you reported against the kernel... it happens every time the chroot is destroyed?<micahg> JFo: yes, but I think it might be related to being in /dev/shm
[18:12] <tgardner> JFo, well, that makes two of us. apw is a bit more familiar with it.
[18:12] <JFo> heh
[18:13] <tgardner> JFo, he's not even running our bits: aufs 2.1-standalone.tree-38-rcN-20110207
[18:14] <JFo> hmmm
[18:14] <tgardner> JFo, the file that the WARNING is coming from is only 396 lines in our version
[18:16] <JFo> tgardner, <micahg> JFo: well, jdstrand added a way to use sbuild in /dev/shm, so I thought I'd try it
[18:16] <JFo> he says he is using the latest kernel: <micahg> JFo: 2.6.38-8.42
[18:16] <jdstrand> uhh, I certainly am not using any other code. all I do is put the sbuild overlay in /dev/shm somewhere
[18:16] <JFo> but where would he have gotten that aufs?
[18:17] <JFo> jdstrand, I think the aufs may be the issue
[18:17] <JFo> but no more than I know... that is like saying the stars are made of really hot cheese
[18:31] <apw_> eagles0513875: did that kernel work?
[18:33] <apw_> bah got bounced
[18:39] <JFo> dang, where has the day gone?
[18:39] <JFo> <-lunch
[18:40] <apw_> it's hiding in the shadowes
[18:43] <tgardner> apw: I was just checking our aufs bits. The SHA1 in the BOM doesn't appear to be valid in the upstream repo.
[18:44] <apw_> will cjeck it out shortly, there is an algo, and two repos to che k
[18:45]  * smb imagines apw_ trying to hit the softkeys while humping along...
[18:45] <cking> the mind boggles
[18:45] <apw_> yep not as easy as it could be, br in front of a stationary one shortly
[18:46] <tgardner> apw: are you someplace weird?
[18:46] <cking> he was in France earlier
[18:46] <tgardner> cking, oh, a train?
[18:46] <smb> I guess a british trains counts as weird...
[18:46] <apw_> on a train for the next half or so
[18:47] <tgardner> apw: ah, well it can wait.
[18:47] <apw_> yep woll look shortly 
[19:03]  * tgardner --> lunch
[19:07] <eagles0513875> apw: hey quick question where can i download a newer version of knetwork manager
[19:20]  * bjf -> lunch
[19:49] <apw> JFo, that bug is mean to be removed from our kernel
[19:49] <apw> (as in the message)
[19:49] <JFo> apw, which?
[19:50] <apw> JFo, the plink one
[19:50] <apw> unless i messed up the kernel update last time
[19:52] <JFo> ok, anything in particular I need to do to it? 
[19:52] <JFo> or wait and see?
[19:57] <apw> JFo, oh its a different one, hrm
[19:57] <JFo> :)
[19:58] <JFo> I'm on a full pot of coffee it could have been anyth.... OMG pwnies!
[20:00] <apw> JFo, heh i bet
[20:00] <JFo> :)
[20:00]  * jjohansen -> lunch
[20:00] <JFo> the sad part is, I didn't realize I drank the whole thing until I went for another refill :-/
[20:03] <apw> ok tgardner this version of aufs seems to be the one in the tree i have; it seems to be a few commits behind which i can look over for sru but it does correspond
[20:04] <tgardner> apw: you're looking at bug #764273 ?
[20:04] <ubot2> Launchpad bug 764273 in linux "WARNING: at /build/buildd/linux-2.6.38/ubuntu/aufs/plink.c:450 au_plink_put 0x4c/0xa0 aufs " [Medium,Incomplete] https://launchpad.net/bugs/764273
[20:05] <apw> well i was answering your previous comment that the BOM commit id didn't exist
[20:05] <apw> (which i contend it does) and that WARN_ON seems to be on that line in the natty source
[20:06] <tgardner> apw: hmm, then one of us is doing drugs.
[20:07] <apw> COMMIT: 65835da20b77c98fb538c9114fc31f5de1328230
[20:07] <apw> is in the BOM
[20:08] <tgardner> apw: agreed.
[20:08] <tgardner> rtg@lochsa:~/proj/linux/aufs2-standalone$ git log -p 65835da20b77c98fb538c9114fc31f5de1328230
[20:08] <tgardner> fatal: bad object 65835da20b77c98fb538c9114fc31f5de1328230
[20:08] <apw> commit 65835da20b77c98fb538c9114fc31f5de1328230
[20:08] <apw> Author: J. R. Okajima <hooanon05@yahoo.co.jp>
[20:08] <apw> Date:   Thu Feb 3 04:46:48 2011 +0900
[20:08] <apw>     aufs: possible bugfix, exclude the freeing file
[20:08] <apw> ahh yes, its not a direct commit id in that tree
[20:08] <apw> its the commit id as listed in the Changelog
[20:09] <apw> which is the id in the aufs main tree that the commit in the standalone tree was made from
[20:10] <tgardner> apw: ok, I'll take your word for it. the real issue is that I don't think he's running _our_ version of aufs. 'WARNING: at /build/buildd/linux-2.6.38/ubuntu/aufs/plink.c:450 au_plink_put+0x4c/0xa0 [aufs]()' references a line number that doesn't exist.
[20:10] <apw> tgardner, the problem is that the primary tree is increadibly slow
[20:11] <apw> tgardner, in my tree here this is the plink.c:450 which look plausable
[20:11] <apw>         WARN(verbose && !list_empty(plink_list), "pseudo-link is not flushed");
[20:11] <apw> and the panic information looks like its 8.42
[20:11] <tgardner> apw: ya know, I might have been on the wrong branch. shit.
[20:12] <apw> heh happens to the best of us
[20:12] <cking> more coffee required methinks
[20:13] <apw> maybe soo indeed
[20:13] <JFo> none for me thanks... 
[20:13]  * JFo has the jitters
[20:16]  * apw slaps JFo ... 
[20:16]  * JFo jumps 10 feet in the air
[20:16] <JFo> :)
[20:17] <apw> now that i want on youtube
[20:19] <JFo> heh
[20:21] <cking> dear bisected kernel, please don't misbehave, it makes bisecting very difficult...
[20:21] <apw> cking, i hate those days
[20:22] <cking> just when you think you've cornered it, it jumps out of reach
[20:40] <JFo> do we care about bug 763656 or should that go to skype?
[20:40] <ubot2> Launchpad bug 763656 in linux "general protection fault: 0000 [#1] SMP " [Undecided,New] https://launchpad.net/bugs/763656
[20:40] <JFo> since they were installing skype when it happened
[20:40] <apw> well there is little we can actually do about it
[20:41] <JFo> I thought that might be the case
[21:39]  * JFo needs a bit of a break: bbiab
[22:20] <bjf> JFo, i've submitted a merge request for apport changes which remove all the user-input from the linux source package-hooks
[22:20] <bjf> pgraner, ^
[22:20] <bjf> JFo, pgraner bug #765178
[22:20] <ubot2> Launchpad bug 765178 in apport "remove user-input questions from linux source package hooks" [Undecided,New] https://launchpad.net/bugs/765178
[22:28] <pgraner> bjf, ack
[22:29] <bjf> pgraner, by the way *I HATE BZR*
[22:29] <pgraner> bjf, :-D
[22:40] <JFo> ok