[06:09] <bullgard4> Does the following relation hold? 2.6.35-22-generic = linux+v2.6.35.6
[06:17] <RAOF> bullgard4: No; I don't even think the weaker relation 2.6.35-22-generic >= linux+v2.6.35.6 holds.
[06:30] <bullgard4> RAOF: So what linx kernel number comes next to Ubuntu's kernel version 2.6.35-22-generic?
[06:30] <bullgard4> s/linx/linux/
[06:38] <ikepanhc> bullgard4: IIRC .35-22 kernel based on 2.6.35.4
[06:40] <ikepanhc> maybe "based on" is not the best word..
[06:40] <bullgard4> ikepanhc: Thank you very much for your help.
[06:40] <RAOF> You could also use git to determine that.  Although my git is currently taking the opportunity to garbage collect.
[07:22] <lucent> I haven't written the list or filed a bug report yet, I'm still confused about where my problems are coming from, with firewire and the new firewire stack
[09:20] <sander^work> Seems like someone deleted a file in yours ppa repository: http://pastebin.com/e8RRyxUW getting: W: Failed to fetch http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu/dists/karmic/main/binary-amd64/Packages.gz  403  Forbidden
[09:21] <sander^work> Are anyone able to fix it?.. or know who can fix it?
[09:23] <smb`> hm, karmic. there should be nothing newer than proposed for that anyways...
[09:23] <smb`> apw, Did you do some cleanups yesterday
[09:25] <smb`> sander^work, Give me a bit. I will check on that
[09:30] <smb`> sander^work, Actually I don't think the generic PPA there ever had Karmic packages... What are you looking for?
[09:35] <sander^work> smb`, W: Failed to fetch http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu/dists/lucid/main/binary-amd64/Packages.gz  403  Forbidden
[09:36] <sander^work> smb`, I tested on karmic instead of lucid.. but same thing happens.
[09:38] <smb`> sander^work, Hm when I wget the link you just posted I succeed. Does that fail for you as well?
[09:38] <sander^work> smb`, works to wget
[09:39] <smb`> sander^work, Do you have any proxy defined for apt?
[09:39] <apw> smb`,  no i didn't do anything to the PPA, though yes we did talk about cleaning it up.  if the package lists were affected that isn't anything i'd have control over or access to though
[09:39] <sander^work> smb, I think so.. How do I remove it?
[09:40] <smb> apw, Right. I thought it might be related to not having any package for that release
[09:40] <apw> smb, sander^work, i can wget that URL no problem so its not LP
[09:40] <smb> apw, btw, clean up pre-proposed just now
[09:40] <apw> smb, was there lots of hidden cruft in there (as rtg suggested) ?
[09:41] <smb> sander^work, it might be defined in /etc/apt/apt.conf or even encoded in the url in the sources.list
[09:41] <smb> apw, Yes, you had even to go to delete to actually see them
[09:41] <apw> heh talk about making it difficult to see ... we should switch the PPAs to a group ...
[09:41] <apw> will try and find out how one might do that at the sprint
[09:42] <smb> Right, that makes us close enough to bend an arm of is... Though that probably is not very well advised
[09:42] <apw> :)
[09:42] <apw> best way to get ones hand bitten off for sure
[09:43] <smb> or ripped :-P
[09:43] <sander^work> smb, thanks! :-).. is there any reason to use a proxy?
[09:44] <smb> sander^work, Depends. Usually I use a proxy like apt-cacher-ng to have packages cached locally. So it does not need to download it all the time.
[09:44] <apw> sander^work, most of us use them to use a caching proxy to reduce our downloads when we ahve many machine
[09:44] <apw> jinx
[09:44]  * smb tries to remember what he had to say. Or was it nothing at all
[09:44] <sander^work> Wondring why it failed now then.
[09:45] <smb> That would depend on where your proxy is and whether it is running
[12:02] <ara> Hello all
[12:02] <ara> In the last couple of days, after using two USB sticks in maverick, they are not recognized anymore
[12:03] <ara> when I insert any of those two, no activity shows up in dmesg and lsusb does not show  them
[12:18] <apw> ara, when you insert them in the same maverick machine ?
[12:35] <ara> JFo, morning! are you around?
[12:37] <ara> where are the kernel people when you need them? :)
[12:39] <ikepanhc> ara: I just have a test, two usb key inserted into maverick machine 'almost' the same time, they all recognized.
[12:40] <ikepanhc> ara: you insert them one-by-one or in the same time?
[12:40] <ara> ikepanhc, they were recognized before
[12:41] <ara> ikepanhc, and some of them are still recognized
[12:41] <ara> ikepanhc, but, these two, no longer recognized
[12:41] <ara> dmesg shows no activity
[12:42] <ikepanhc> ara: is the output of lsusb different before and after usb key inserted?
[12:42] <JFo> ara, I am :)
[12:43] <JFo> sorry for the delay, was working on another machine for the moment
[12:43] <ara> ikepanhc, no, already tried that as well
[12:43] <ikepanhc> JFo: good morning :)
[12:43] <JFo> ikepanhc, good morning :)
[12:43] <ara> JFo, I am just having some USB key issues :)
[12:43] <JFo> uh oh :)
[12:44] <ara> they are not recognized anymore (two of them)
[12:44] <JFo> interesting
[12:44] <JFo> no new mount info?
[12:44] <JFo> after you insert them?
[12:45] <ara> nothing, no dmesg activity, no lsusb, niente
[12:45] <ara> dead
[12:45] <ara> kaput
[12:46] <JFo> huh
[12:46] <ara> and it had happened already with two of them
[12:46] <JFo> both the same make or different?
[12:47] <ara> the same make?
[12:47] <JFo> same manufacturer and possibly model
[12:47] <JFo> sorry :)
[12:48] <ara> they are not same model
[12:48] <ara> as for the manufacturer, no idea, both are marketing keys
[12:48] <JFo> ok
[12:48] <JFo> hmmm
[12:49] <ara> one is Ubuntu, if you know their maker
[12:53] <JFo> I'm not sure what we should do here.
[12:53] <JFo> apw, any thoughts about ara's USB issues?
[12:54] <apw> seems she missed my reply:
 when I insert any of those two, no activity shows up in dmesg and lsusb does not show  them
 ara, when you insert them in the same maverick machine ?
[12:54] <apw> * ara_ is now known as ara
[12:54] <apw> i assume she was bounced, and i didn't notice
[12:55] <ara> apw, when they started not being recognized, they are not recognize in two differnt maverick machines
[12:55] <apw> ara will you be at release sprint ?
[12:55] <apw> they sound like dead keys, but it is odd you lost two in a day
[12:55] <apw> nothing in dmesg at all is not normal for sure
[12:58] <ara> apw, if maverick is breaking keys... 
[12:58] <apw> ara, well indeed, that is a possibility, though i have little idea how that could be so ... we don't have that low a level of access to them
[12:59] <apw> how old are these keys, are they ones from our shop ?
[12:59] <apw> i use sticks pretty often with my maverick installs and have not yet had anything similar occur
[12:59] <ara> one of them is the classic ubuntu 4gb one, yes, I won it in the last all hands ;-)
[12:59] <apw> cking, you use sticks endlessly .... anything like this occured on maverick for you?
[13:00] <apw> ara, i have a number of those ones too, obtained somewhere or other
[13:05] <cking> apw, not seen this issue
[13:10] <smb> lsusb would be sort of second stage show up. if there is not even errors or anything in dmesg when the sticks are plugged in it seems not even the controller reacts
[13:11] <smb> ara, just to confirm some other than these two work on the same usb ports, just the two show no reaction at all
[13:13] <ara> smb, yes, that's it
[13:15] <ara> well, maybe it is just a strange coincidence. both were destined to die 10 days apart :)
[13:15] <smb> The accumulation of two in a row is a bit odd. Hm, its not the time of year with increased static discharges... 
[13:15] <smb> yeah
[13:16] <ara> lunch time for me
[13:16] <smb> One thing to try may be to put them in and press them down or up a little....
[13:16] <smb> Strange enough that helped on one of the usb wireless keys I got
[13:34] <apw> yeah that one was an oddie
[13:35] <ogra> hmm
[13:35] <ogra> is there any way to compile a kernel in a awy that init= doesnt work ?
[13:35] <ogra> *way
[13:37]  * ogra has a weird device with android kernel and its neither possible to use a shellscript as /init nor can i override init with the cmdline param
[13:38] <smb> Nobody could prevent someone from modifying the kernel code not to parse for init I guess
[13:38] <ogra> ah, damned
[13:38] <jk-> ogra: is ti running from a ramdisk? maybe try rdinit= ?
[13:38] <jk-> s/ti/it/
[13:38]  * ogra tries
[13:39] <apw> ogra, indeed, they have likely removed the option for security
[13:39] <ogra> "security" ... pfft 
[13:39] <cking> where there is a will, there is a way..
[13:40] <ogra> locking out users to use the HW with their desired OS i'd say
[13:40] <ogra> they dont provinde the kernel source either
[13:40] <ogra> *provide
[13:40] <apw> hrm, now i am supprised they can do that
[13:41] <cking> they should provide source for sure
[13:41] <ogra> yes
[13:41]  * ogra ponders to report to http://www.gnu.org/licenses/gpl-violation.html
[13:42] <ogra> but the device is brandnew so i dont want to be harsh and give them some days
[13:43] <ogra> its basically just an android kernel but there are some HW specific patches without which you cant move on
[14:17] <tgardner> bjf, how come you uploaded Lucid mvl-dove again? as far as I can tell you only bumped the ABI, yet the previous build appeared to be OK.
[14:18] <smb> tgardner, uploaded again compared to what?
[14:18] <smb> the last upload would include a rebase to latest master and some updates from eric
[14:19] <tgardner> smb, he uploaded yesterday with Ubuntu-2.6.32-210.27, then again this morning with Ubuntu-2.6.32-211.27
[14:20] <tgardner> I guess there must have been an FTBS since the the diffs jump from 209.25 to 211.27
[14:20] <smb> tgardner, I believe the 210-27 had the abi bump from a previous upload but since then the patches from eric required another bump
[14:35] <tgardner> bjf, lemme know when your iso builder is done so I can bounce tangerine
[15:17] <bjf> tgardner, got for it, looks like it ran into problems
[15:44] <apw> ogasawara, /me is starting to put together the skeleton blueprints for natty, just so we don't duplicate effort
[15:45] <ogasawara> apw: cool
[15:45] <ogasawara> apw: once you're done, we can start picking the one's off that need some prep work (eg the delta blueprint, etc)
[15:45] <apw> ogasawara, indeed so
[16:08] <bjf> ##
[16:08] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:08] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[16:08] <bjf> ##
[16:55] <ogasawara> apw: your patch to reduce disk usage on buildd's, should we throw that in the day-0 kernel?
[16:56] <apw> ogasawara, it doesn't really need uploading as such, as i understand things it only really impacts the PPA builders
[16:56] <apw> ogasawara, so it needs to be in our tree, but not urgently in an upload
[16:57] <ogasawara> apw: ack, I'll put it in the holding pattern then
[16:57] <apw> heh do we have a branch called that ? :)
[16:57] <ogasawara> heh, no
[17:05] <JFo> apw, there was something we wanted to discuss in the AOB bit of today's meeting... do you remember what it was?
[17:05] <apw> JFo, there was?  hrm, where were we when we talked about it ?b
[17:05] <JFo> Taipei
[17:05] <JFo> I'm drawing a blank as well
[17:05] <apw> helpful!
[17:05] <JFo> heh indeed
[17:05] <JFo> we were in the office
[17:06] <JFo> hmm
[17:06] <JFo> wonder if it was about the kernel-input tagged bugs for review
[17:07]  * apw is still blank
[17:08] <JFo> ah well
[17:08] <JFo> no matter
[17:08] <JFo> if it is important
[17:08] <JFo> we will remember eventually
[17:18]  * jj-afk needs to run his kids to school, back in 15
[17:18] <jj-afk> he oops, forgot to change my nick
[17:39] <bjf> ##
[17:40] <bjf> ## Kernel team meeting in 20 minutes
[17:40] <bjf> ##
[17:55] <bjf> ##
[17:55] <bjf> ## Kernel team meeting in 5 minutes
[17:55] <bjf> ##
[18:03] <lamont> apw: if you could post how to limit flavors, or drop ddebs to bug 645653, that would be very wonderful as a workaround, I expect (hope?)...
[18:03] <ubot2> Launchpad bug 645653 in linux (Ubuntu) "kernel is unbuildably large (affects: 1) (heat: 8)" [High,In progress] https://launchpad.net/bugs/645653
[18:03] <apw> lamont, the patch to fix that is on our kernel-team list
[18:05] <lamont> yeah - It's just that it'd be good to have a URL to point people at when I kill their builds that are tying up ppa builders, and the bug seems the cleanest place to point them
[18:05] <apw> lamont, ok so probabally attaching the patch is the cleanest soln then
[18:05] <lamont> ta
[18:12] <apw> lamont, done
[18:20] <avinash_hm> hi, i have a program generating seg fault ... i wan't to dump the core file .. it's not getting dumped...'ulimit -c' is unlimited .. anyone noticed this issue
[18:20] <avinash_hm> i am using 10.04 ubuntu
[18:24] <vanhoof> avinash_hm: where are you dumping it, local fs?
[18:25] <avinash_hm> vanhoof, its in my home directory
[18:25] <vanhoof> avinash_hm: is it suid?
[18:25] <avinash_hm> vanhoof, no .. shall i log as root and try
[18:26] <vanhoof> avinash_hm: nah, was wondering if you needed to fiddle w/ suid_dumpable
[18:26] <vanhoof> and i've seen weird problems in the past dumping core on a nfs based fs
[18:26] <vanhoof> avinash_hm: can you reproduce this with something other than your app
[18:26] <vanhoof> say something like this ...
[18:27] <vanhoof> avinash_hm: http://paste.ubuntu.com/502225/
[18:28] <avinash_hm> vanhoof, let me try
[18:29] <vanhoof> make sure you done have /proc/sys/kernel/core_pattern set to something that would dump outside of your cwd
[18:29] <vanhoof> and if its an app thats stared at boot, you should check its cwd as well
[18:30] <vanhoof> or set core_pattern to somewhere constant
[18:32] <avinash_hm> vanhoof, http://pastebin.com/XTwHxdmQ .. not generating .. core_pattern is core .. so cool on that side
[18:33] <kamal> vanhoof, avinash_hm: can I butt in?
[18:33] <vanhoof> kamal: sure
[18:33] <kamal> avinash_hm: see whether you can make anything core dump...  Try putting this file into /tmp, compiling it, and running it:
[18:33] <avinash_hm> sure
[18:34] <kamal>   /* crashy.c */  int main() { int *p=0; return *p; }
[18:34] <kamal> try it in /tmp specifically, so as to avoid any potential issue with the directory you're working in there.
[18:34] <kamal> does it dump core?
[18:34]  * vanhoof is curious what /media/windows-pc is ... and what mount options are associated w/ it
[18:35] <kamal> vanhoof: yes -- my thinking exactly ;-)
[18:35] <avinash_hm> kamal, core dumped ... 
[18:36] <avinash_hm> vanhoof, /media/windows-pc .. this is my windows drive .. its 200+ gb .. so mounted it and started accessing it
[18:36] <kamal> avinash_hm: ok, try copying the your built binary into /tmp, and run it there.  dump core?
[18:38] <avinash_hm> kamal, no .. didn't dump .. but more or less its your code .. http://pastebin.com/sjFMiEK3
[18:40] <kamal> avinash_hm: when I compile that (gcc -o avi avi.c) it does dump core for me.
[18:42] <avinash_hm> kamal, u compiled as a sudoer .. ?? i logged as su and core dumped :-(
[18:43] <kamal> avinash_hm: I don't think it should matter how it was compiled
[18:44] <kamal> avinash_hm: what happens if you change your code to be more like mine?  take out the printf, and try just "return *c".   (if you can make my code dump, yours should too, lets find the difference).
[18:45] <avinash_hm> let me try ur code in my home .. [ old dir [
[18:47] <avinash_hm> kamal, again no luck .. http://pastebin.com/dqRYbYnq .. may be somthing to do with permissions
[18:47] <kamal> avinash_hm: but you're back in that /media/windows-pc directory again!  I think *that* is the problem.  try your code in /tmp.
[18:48] <kamal> actually just try running the *binary* in /tmp
[18:50] <kamal> avinash_hm: note also that this should even work:
[18:50] <kamal>    cd /tmp
[18:50] <kamal>    /media/windows-pc/linux-home/avi-projects/learn-c-programming/AOD/crash
[18:50] <avinash_hm> kamal, yeah .. running binary .. [ mine, yours ] works in /tmp ... doesnt work in AOD
[18:50] <kamal> (that should leave you with /tmp/core)
[18:50] <avinash_hm> yep ...
[18:51] <avinash_hm> let me go ahead with this dump generated for now ... 
[18:51] <avinash_hm> thanks kamal, vanhoof for the help ... 
[18:51] <kamal> ok, so the problem is something about the mount options with that mounted directory -- I don't know how to "fix" that -- but yes, I think your best bet is to just arrange to dump core elsewhere.  :-)   glad we could help!
[18:52] <avinash_hm> possible .. avinash@avinash-laptop:/tmp$ mount | grep windows
[18:52] <avinash_hm> /dev/sda3 on /media/windows-pc type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)
[18:53] <avinash_hm> thanks again kamal :-) .. have fun
[19:15]  * tgardner lunches
[19:42] <savvas0> JFo: hi, I was told that you can help include a post-update regarding maverick -- is it possible to include the new carl9170 which would improve performance of some atheros based usb wireless devices? bug 540827
[19:42] <ubot2> Launchpad bug 540827 in linux (Ubuntu) (and 1 other project) "ar9170usb wifi module crash + instabile connection (affects: 16) (dups: 2) (heat: 84)" [Undecided,Confirmed] https://launchpad.net/bugs/540827
[19:42] <JFo> hi savvas0 
[19:42]  * JFo looks at the bug
[19:43] <savvas0> thank you for your time :)
[19:43] <JFo> savvas0, no problem, but let's see how much help I am :)
[19:44]  * savvas0 crosses fingers heh
[19:44] <JFo> tgardner, do you know anything about the firmware mentioned in that bug? ^^
[19:45] <JFo> hmmm, he is at lunch
[19:45] <JFo> savvas0, let me check with tgardner when he returns to see what has been done/needs to be done
[19:45] <JFo> sound good?
[19:46] <savvas0> sure, works for me -- if not for maverick, then for ubuntu+1+1 :)
[19:46] <savvas0> thanks again
[19:46] <JFo> my pleasure
[19:47] <JFo> I'll ping you once he gets back in case we need to discuss :)
[19:48] <savvas0> alright, I'll stick around then
[19:54] <hackeron> anyone able to get linux-crashdump working on maverick? - I installed it, rebooted, induced a panic but can't see anything in /var/crash - any ideas?
[20:07]  * ogasawara lunch
[20:11] <JFo> hackeron, I vaguely recall some conversation around that
[20:11] <JFo> but I don't recall specifics
[20:17]  * jjohansen -> lunch
[20:19] <hackeron> JFo: heh, hmmmmm
[20:21] <JFo> hackeron, if I had to guess I'd say there was a reason we don't have it in by default, but I want to say we had some wiki info on it
[20:21] <JFo> I am looking
[20:22] <hackeron> JFo: thanks
[20:22] <JFo> hackeron, my pleasure
[20:22] <smoser> Daviey, what 'apt-get' do i need ?
[20:22] <smoser> oops
[20:22] <smoser> wrong window
[20:23] <JFo> heh
[20:23] <JFo> no sweat smoser 
[20:24] <JFo> apw, if you are still around, do you recall the kernel-crashdump conversation?
[20:24] <JFo> I can't seem to find a page on it hackeron 
[20:24] <JFo> still looking
[20:25] <JFo> hmmm, may have found some stuff hackeron 
[20:25] <JFo> one sec...
[20:25]  * JFo reads it
[20:26] <JFo> you saw this already hackeron? https://wiki.ubuntu.com/Kernel/CrashdumpRecipe
[20:26] <JFo> not really much there
[20:26] <hackeron> JFo: yeh, doesn't work on maverick :(
[20:27] <JFo> :-(
[20:27] <JFo> everything else I see is old
[20:28] <JFo> ogasawara, any memory about kernel-crashdump?
[20:28] <JFo> oh, she is probably at lunch
[20:28] <JFo> hmmm
[20:29]  * JFo digs further
[20:33] <JFo> so hackeron you get E:Unable to locate package kernel-crashdump also?
[20:33] <JFo> that is what I see on my Mav machine
[21:06] <scrllock> does anyone know which kernel versions include pv-on-hvm drivers?
[21:15] <ogasawara> JFo: I haven't looked at crashdump for a few releases so probably can't add anything of use
[21:15] <JFo> ogasawara, cool
[21:15] <JFo> thanks
[21:15] <JFo> scrllock, I do not
[21:15] <JFo> sorry :-/
[21:16] <scrllock> i'm reading stuff (meeting notes, mainly) indicating that jjohansen was looking into putting something into a PPA, but i haven't found anything other than that
[21:17] <apw> i don't recall anything specific occuring with those, once the pv-ops kernel started working right
[21:17] <apw> wern't they a fall back?
[21:17] <scrllock> afaik, it lets you set up a hvm guest with paravirtualized i/o drivers, for performance reasons
[21:20] <apw> they may know more specifically on #ubuntu-server, as they are the main drivers of the server side functionality such as that
[21:20] <scrllock> thank you, i'll look there
[21:25] <hackeron> JFo: no, it installs, just nothing appears in /var/crash when I induce a panic
[21:25] <JFo> hmmm
[21:25] <JFo> wonder why I am having issues
[21:25] <JFo> k hackeron thanks for the update. I'll keep looking
[21:32] <jjohansen> scrllock: the pv-on-hvm drivers have been on hold behind maverick items
[21:34] <jjohansen> scrllock: the ppa should be up in the next couple weeks
[21:41] <scrllock> jjohansen: will that be announced somewhere?
[21:42] <jjohansen> scrllock: yeah, server team list, and meeting
[21:43] <scrllock> jjohansen: excellent, thank you very much, i appreciate it
[21:59] <hackeron> JFo: any luck?
[22:00] <JFo> hackeron, sadly no
[22:00] <JFo> got puled of on something else
[22:00] <JFo> but I still don't see anything
[22:00] <JFo> jjohansen, any memories about kernel-crashdump?
[22:01] <JFo> I recall a recent conversation
[22:01] <JFo> but I haven't found anything on it yet
[22:01] <JFo> and I seem to be unable to install it in the normal way
[22:01] <JFo> on Mav
[22:01] <jjohansen> JFo: paging ...
[22:03] <jjohansen> hrmm, no nothing atm
[22:03] <JFo> k
[22:03] <JFo> thanks 
[22:03] <jjohansen> JFo: what do you mean it want install in the normal way
[22:03] <JFo> hackeron, may have to ask tgardner tomorrow
[22:04] <JFo> jjohansen, from what I found it should be an apt-get
[22:04] <JFo> but it fails
[22:04] <JFo> works on Lucid
[22:04] <JFo> hackeron, has it installing on Maverick
[22:04] <jjohansen> how does it fail?  What is the message?
[22:04] <JFo> but not leaving the crashdump
[22:04] <jjohansen> hrmmm strange
[22:04] <hackeron> JFo: yep
[22:05] <JFo>  E:Unable to locate package kernel-crashdump
[22:05] <JFo> that from my maverick box
[22:05] <JFo> wonder if the package just got overlooked
[22:05] <JFo> or smth
[22:06] <JFo> well, that can't be right
[22:06] <JFo> if hackeron got it to install on Maverick
[22:07] <jjohansen> JFo: so you are getting E:Unable to locate package kernel-crashdump
[22:08] <JFo> yep
[22:08] <jjohansen> hrmm, did you do an update before trying to install
[22:08] <jjohansen> sudo apt-get update
[22:08] <hackeron> JFo: I'm using deb http://gb.archive.ubuntu.com/ubuntu/ maverick including partner, universe and multiverse
[22:08] <jjohansen> I just installed it no problems
[22:08] <JFo> ah
[22:08] <JFo> wait a tick
[22:09] <hackeron> maybe it's in universe or something?
[22:09] <JFo> I R Dumb
[22:09] <JFo> I was trying to do kernel-crashdump
[22:09] <JFo> it is linux-crashdump
[22:10] <jjohansen> :)
[22:10] <JFo> I actually called it properly from my Lucid machine
[22:10]  * JFo headdesks
[22:10] <JFo> k, that installed
[22:11] <JFo> now to why it didn't do the crashdump properly
[22:11] <JFo> I've no clue
[22:16] <jjohansen> JFo, hackeron: yama maybe
[22:17] <JFo> yamo be there?
[22:17] <JFo> :)
[22:17] <jjohansen> give me a sec I am trying to remember the yama controls
[22:18] <JFo> k
[22:20] <jjohansen> JFo, hackeron: try setting yama ptrace scope
[22:21] <jjohansen> cat /proc/sys/kernel/yama/ptrace_scope 
[22:22] <JFo> interesting
[22:22] <JFo> I get 1 on Maverick
[22:22] <JFo> but on Lucid:
[22:22] <JFo> jfo@nightcrawler:~/bzr/kernel-arsenal/contrib/linux$ cat /proc/sys/kernel/yama/ptrace_scope
[22:22] <JFo> cat: /proc/sys/kernel/yama/ptrace_scope: No such file or directory
[22:23] <jjohansen> JFo: yama is new in maverick
[22:23] <JFo> I see
[22:23]  * JFo learns
[22:23] <jjohansen> it adds some basic system wide restriction on hardlinks, symlinks and ptrace
[22:24] <jjohansen> 1 is restricting to child only ptraces
[22:24] <jjohansen> set it to 0 for classic ptrace behavior
[22:31] <JFo> k
[22:34]  * JFo finishes up for the day
[22:34] <JFo> thanks for the information jjohansen :)
[22:34] <jjohansen> night JFo
[22:34] <JFo> night jjohansen