[08:16] <smb> morning
[08:46] <sakthi> hi, can anyone point to right resources in order to form a good foundation in kernel programming..
[10:52] <ppisati> to whom shall i ask for the qa-regression-testing?
[10:55] <smb> ppisati, If I am not confusing people, maybe hggdh. And I guess he'll scream if I did confuse people... 
[10:56] <ppisati> ok, let me try
[10:56] <ppisati> hggdh: ping
[11:44] <gema> ppisati: https://blueprints.launchpad.net/ubuntu/+spec/other-p-qa-qa-regression-testing
[11:44] <gema> ppisati: nuclearbob is the right person to ask
[11:46] <ppisati> gema: k, thanks
[11:47] <gema> np
[14:31] <hggdh> ppisati: hello
[14:31] <hggdh> hum, I see all is resolved
[14:38] <herton> ppisati, just confirming, ti-omap4 rebased on oneiric doesn't change the abi?
[14:39] <ppisati> herton: compilation didn't complain about it so...
[14:39] <herton> ppisati, ack
[15:07] <apw> ppisati, that does assume its enabled !
[15:11] <ppisati> ppisati: uh?
[15:31]  * ogasawara back in 20
[15:37] <lifeboy> If I have a display driver problem on an ltsp client and the screen keeps on initialising every 5-10 seconds, which process to I stop in the console (screen 0) to inspect what's going on?
[15:37] <lifeboy> It's not ldm, startx or xdmcp
[15:39] <apw> bah
[15:40] <apw> lifeboy, i thought it stopped after 5 or so tried
[15:40] <apw> i assume its lightdm which is respawning X if its that
[15:51] <ogra_> lifeboy, better go to #ltsp to debug that ;)
[15:55] <lifeboy> soory, that was posted in the wrong channel! 
[15:55] <lifeboy> I meant to go to #ltsp :-)
[16:32] <herton> is anybody being able to clone from zinc? (I'm getting "fatal: The remote end hung up unexpectedly")
[16:34] <smb> it seems exceptionally crawling
[16:34] <ppisati> yep, really slow today
[16:35] <smb> load of 76
[16:35] <smb> seems to be swapping to death
[16:36] <herton> cloning through ssh:// seems to be going now
[16:45]  * apw bets its those web-crawlers again
[16:45] <smb> apw is right
[16:46] <smb> or has been looking on #is :)
[16:46] <apw> heh not looking on #is
[16:46] <apw> am just talking on #is
[16:47] <smb> apw, I just had been completed to hassle him :)
[16:49] <apw> heh so you had, /me leans on them too
[17:03] <ppisati> GrueMaster: ping
[17:04] <GrueMaster> ppisati: Sup?
[17:08] <GrueMaster> ppisati: You rang?
[17:15] <ppisati> GrueMaster: yes
[17:16] <ppisati> GrueMaster: http://people.canonical.com/~ppisati/linux-image-2.6.35-903-omap4_2.6.35-903.27~lp893190_armel.deb
[17:16] <ppisati> GrueMaster: can you tell me if you still see the ptrace FAILures?
[17:16] <ppisati> GrueMaster: wrt https://launchpadlibrarian.net/85419190/test-kernel-security.log
[17:16] <GrueMaster> And you want me to test it?  I'm flattered.  :P
[17:16] <GrueMaster> Will do.  Give me a few minutes.
[17:18] <l3on> Hi all... does some ppa  exist backporting kernel 3.2.0 on 11.10 ?
[17:39] <GrueMaster> ppisati: Ok, all ptrace errors now resolved.
[17:41] <GrueMaster> I'll have to talk with smb and kees about the /dev/mem and seccomp errors.  The script indicates they were available in armel kernels beginning with 2.6.35.
[17:42] <GrueMaster> Maybe they were in the omap kernel?  I don't have access to my beaglexm this week, but can check next week when I get home.
[17:43] <ppisati> GrueMaster: for sure these were not available in maverick/omap*
[17:43] <ppisati> GrueMaster: the exact kernel release after that (.36), had them
[17:43] <ppisati> anyway thanks
[17:43] <GrueMaster> btw:  Tomorrow is a national holiday, andI will also be offline Friday.
[17:44] <GrueMaster> ppisati: Ok, I will update the script then.
[17:49] <ppisati> ok
[18:16] <GrueMaster> Grrr.   When making changes to the test-kernel-security script for armel, kees also turned on a blanket test for SECCOMP (which didn't exist in <2.6.36 armel kernels). 
[18:16]  * GrueMaster facepalms
[18:20] <GrueMaster> test_070_config_seccomp fails because not only was it not enabled until 2.6.36 on armel, it didn't exist as an option.  New false failure introduced on all <natty armel platforms (babbage3, dove, omap4).  Wheee.
[18:23] <GrueMaster> ppisati: Was SECCOMP something that was backported to the x86 kernels?  I'm trying to figure out why it doesn't even exist on any of my armel kernels.
[18:27]  * ogasawara bails.  see ya'll next week.
[18:28] <tgardner> GrueMaster, you might be a bit  late for Paolo. its 7:30P in Italy.
[18:28] <ppisati> no, i'm still around
[18:30] <ppisati> GrueMaster: natty/omap4 has it
[18:31] <ppisati> GrueMaster: it has entered linus tree in 2.6.36-rc7
[18:34] <GrueMaster> ppisati: Thanks.  Now need to wrap this new code change.
[18:37] <jsalisbury> herton, bjf, regression from 3.0.0.12 to 3.0.0.13: bug 893876
[18:37] <ubot2> Launchpad bug 893876 in linux "wrong display-resolution and no compiz-unity-plugin working since Kernel 3.0.0.13" [Medium,Confirmed] https://launchpad.net/bugs/893876
[18:39] <herton> jsalisbury, ok, .13 is already released so if having a solution a fix will land in a later update
[18:39] <jsalisbury> herton, thanks
[18:43] <jsalisbury> tgardner, Is there a way to match up commits reported by "git log" with what is in the ~/debian.master/changelog for the same kernel tree?
[18:45] <herton> jsalisbury, it seems 893876 is not a kernel regression. On the working previous kernel, the user has nvidia proprietary driver loaded, but not on new kernel for some reason, thus the vesafb which is always loaded seems to be used
[18:45] <herton> (checking both dmesgs on the report)
[18:45] <jsalisbury> herton, ahh, ok.  
[18:47] <tgardner> jsalisbury, typically all commits in a version go into the changelog unless they are administrative (and therefore ignored)
[18:47] <apw> jsalisbury, yes the commit titles are the one liners
[18:47] <jsalisbury> tgardner, apw, great, thanks for the info!
[18:48] <jsalisbury> apw, so I can grep for the one liners in the changelog
[18:49] <tgardner> jsalisbury, if you know the commit SHA!, then you can 'git describe --contains <SHA1>' to get the most recent tag.
[18:50] <apw> jsalisbury, yep
[18:50] <jsalisbury> tgardner, apw, cool, thanks for the help
[18:53] <jsalisbury> herton, for 893876, do you think they need to configure the new kernel to use the nvidia driver, it won't happen automatically?
[18:55] <herton> jsalisbury, no idea, I don't know how nvidia is installed, or how the user installed, I know we have jockey to enable the binary drivers, don't know how that works out in detail.
[18:56] <jsalisbury> herton, ok.  I'll update the bug and report your findings.  Thanks for reviewing.
[18:56] <herton> jsalisbury, ok, it's worth asking the reporter about how he installed, and checking if nvidia driver is built/enabled with the new kernel
[19:00] <jsalisbury> herton, ok, will do.  thanks
[19:25]  * herton back in 30 min-1 hour (errand)
[20:01] <cemc> hi. I'm trying to rebuild the Hardy kernel package. I've applied a one-liner to fix some bug and I'm trying to build it using pbuilder (or through the PPA), but I'm getting the following: https://launchpadlibrarian.net/85751961/buildlog_ubuntu-hardy-i386.linux_2.6.24-30.96%2Bcemc1_FAILEDTOBUILD.txt.gz . I'm not sure how the ABI stuff works. I've just renamed the directory in debian/abi/ and changed the abiname from 29 to 30. I also read the kernel b
[20:01] <cemc> uilding wiki page but I don't see what I need to do
[20:01] <cemc> does anybody have a minute to give me some pointers?
[21:05] <herton> cemc, for a test build, just bumping the abi should be enough, no need to rename the directory in debian/abi, I guess it's what breaking your build
[21:07] <cemc> herton: you mean in debian/changelog?
[21:07] <herton> cemc, yes
[21:08] <cemc> herton: the kernel in Hardy is 2.6.24-30.96, and I just added a +cemc1 to that, I didn't want to change the version so I know it's the same kernel just with my changes
[21:08] <cemc> curiously enough, the last one -29.95 did work like this
[21:16] <herton> cemc, what would be the right way to do it, starting from a pristine 2.6.24-30.96, is something like "debian/rules startnewrelease", get the abis from the current release (you can use "./debian/scripts/misc/getabis 2.6.24 30.96"), then remove old abi dir in debian/abi, bump the abi, apply your patch(es)
[21:16] <herton> but I don't know if you need to do this for a test build, I would expect just applying the patch on top of .30 should work
[21:20]  * herton -> eod
[22:31]  * tgardner -> EOD
[23:00] <shabble> does anyone have any experience with writing/mangling usb(-serial) drivers? I'm in a weird place where cdc-acm is needed to init the device, but I have to unload and replace it with usbserial (generic) otherwise it locks up the port.
[23:01] <shabble> it's an MSP430 test board: RF2500 - there's plenty of threads about it being pretty horrible, but sadly nothing that seems to actually fix it.