[09:28] <apw> henrix, when we did natty did we also do natty/ti-omap4 ?
[09:29] <henrix> apw: i'm not sure about that. let me check...
[09:54] <thierry> Hi everyone, i'm working on an ubuntu-server image on my Pandaboard - :) - and i'm trying to connect a GPS / RFID  / GPRS to my system; the problem is that in a normal ubuntu environment theses devices are attached on /dev/ttyUSB* ( for GPS and GPRS) and /dev/ttyACM* ( for RFID) but on my system they are plugged on /dev/usbdev*.**
[09:54] <thierry> i found some tutos that show how to enable usbserial for devices using their idProduct / Vendor : but i need this to be natively done by the system , regardless the GPS i'm connecting 
[10:03] <thierry> i've also to mention that for RFID i see in dmesg output : ttyACM0 : USB ACM device but when i check /dev , no ACM entries are there except the newly created usbdev2.1 and for GPS also dmesg tells FTDI USBSerial Device converter now attached to ttyUSB0 but also i can't fin d this entry in /dev but i see that usbdev has been created!
[10:05] <thierry> i've also to mention that for RFID i see in dmesg output : ttyACM0 : USB ACM device but when i check /dev , no ACM entries are there except the newly created usbdev2.1 and for GPS also dmesg tells FTDI USBSerial Device converter now attached to ttyUSB0 but also i can't fin d this entry in /dev but i see that usbdev has been created!
[10:25] <apw> henrix, ok i have pushed the missing CVE commits to ti-omap4 so when you make it it should be complete.  commentary to kernel-team@ for the record.
[10:26] <henrix> apw: ok, thanks. i'll need to sync with herton, as he's doing all the omap4 kernels (with ppisatti)
[10:27] <apw> thierry, might be a configuration option missing or something, do you have a bug filed?
[10:27] <ogra_> FTDI also often misses vendor/product IDs 
[10:28] <apw> ogra_, FTDI ?
[10:28]  * ogra_ had some devices that needed a manual fix to then show up properly in the next kernel iteration)
[10:28] <ogra_> apw, serial driver
[10:28] <apw> ogra_, well the implication of the above is that the device works in an x86 kernel at the same level
[10:30] <ogra_> apw, right, that would apply if he used the same kernel versions on both arches ;)
[10:31] <apw> ogra_, indeed, and hopfully the bug has that info ... 
[10:31] <apw> ogra_, as i think other than natty things are rebase so should be in sync, if its natty they just missed the boat
[10:34] <thierry> apw:  configuration files i've missed or that aer missing in ubuntu-server? 
[10:35] <ogra_> thierry, no, we were talkin abot kernel build configuration
[10:40] <apw> thierry, indeed what ogra_ said
[11:20] <bullgard6> http://askubuntu.com/questions/176970/how-can-i-remove-a-mainline-kernel-and-move-back-to-a-supported-kernel/176977#176977 How is a "mainline kernel" defined? How is a "stock Ubuntu kernel" defined? What is the difference?
[11:22] <thierry> ogra_: apw : exactly, i had this problem once before, but it was me building the kernel with options with PTXdist ( hey LetoThe2nd  :) ) ... but there is no way to encoutner this problem????
[11:23] <apw> bullgard6, a mainline kernel is a kernel built from virgin upstream sources, typically though not exclusivly found in the mainline kernel archive (https://wiki.ubuntu.com/Kernel/MainlineBuilds).  A stock ubuntu kernel is one built from our modified sources and delivered via the main archive.
[11:24] <apw> thierry, i don't get you, "no way to encounter this problem?"
[11:25] <bullgard6> apw: Thank you for your help.
[11:25] <thierry> as i've understood, the usbserial driver is not built in , it's included as a module i guess, i have to activate for each device i need, there is no way to rebuild it ?
[11:26] <apw> thierry, i don't think we have said as much as that.  we have suggested that perhaps the kernle you have does not have the same options as the working on you mentioned, here i am assuming arm against x86 kernels are different
[11:26] <apw> thierry, without a real idea of the issue i have no idea what if anything can be done about it
[11:27] <apw> thierry, if activating the serial driver by hand works for you, ie modprobe something makes it work you could probabally just add that module to /etc/modules as a work around
[11:28] <apw> otherwise, some information on what version of the kernel is broken on what platform and what version is working on what platform, would help
[11:34] <thierry> apw: i'm using the 3.4.0-1485-opa4 kernel, an ubuntu-server image ( hey ogra_ ) , on  a Pandaboard B1
[11:36] <thierry> omap* and not opa
[11:37] <apw> thierry, and which one do you find them automatically detected correctly
[11:38] <thierry> for USB-serial devices , no one i have ( i tested an RFID, a GPS and GPRS)
[11:38] <thierry> apw: for USB-serial devices , no one i have ( i tested an RFID, a GPS and GPRS)
[11:41] <thierry> apw:  the sudo echo usbserial >> /etc/modules works 
[11:42] <thierry> should i launch a bug or something like this?
[11:42] <apw> thierry, that information should be in a bug indeed.  include the lsusb output for the devices which don't work
[11:43] <thierry> ok , but in which bugtracker? 
[12:01]  * henrix -> lunch
[14:41]  * ogasawara back in 20
[15:46] <bjf> ogasawara: mumble?
[15:46] <ogasawara> bjf: sure, just a sec
[15:53]  * ogra_ is really happy to see that rtg raised the ulöimit for omap4 kernels too, finally we can run our wine apps properly on the panda :P
[15:54] <rtg> ogra_, it'll take a bit for that change to propagate....
[15:55] <rtg> ogra_, though I'm curious which release you are concerned about ? herton pointed out the Lucid ti-omap is no longer maintained.
[15:55] <ogra_> rtg, well, there is no wine on arm ... (there is but there are no executables to run)
[15:55] <ogra_> rtg, that was pure sarcasm 
[15:56] <rtg> ogra_, oh, I didn't get it :)
[16:40] <jsalisbury> **
[16:40] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:40] <jsalisbury> **
[16:56] <jjohansen> cking: so I have requests to reenable IMA, the problems that caused it to get blacklisted are supposed to be fixed. I asked the maintainer if she had anyway to measure and she said no, so I am looking for ideas on what tests to run etc to verify that we can reenable IMA.
[16:56] <jjohansen> Basically I'd like to pick your brain when you have some time in the next few days
[16:57] <cking> jjohansen, which IMA are you referring to?
[16:58] <jjohansen> cking: CONFIG_IMA its a security module todo with with measuring system integrity.
[16:58] <jjohansen> It got blacklisted in our config due to a bug that caused it to chew up a lot of resources
[16:59] <jjohansen> err bug may not be the right word, they actually kind of designed it to do that without realizing their design choice was bad
[17:00] <cking> jjohansen, OK, I've got zero knowledge on this, but I can ramp up tomorrow morning on it.
[17:01] <jjohansen> cking: yeah I am just a little ahead of you and just looking for ideas, its not a big rush
[17:02] <cking> jjohansen, OK - well let me get upto speed and then we can kick some ideas around.
[17:04] <cking> jjohansen, is there a bug you can refer me to on this?
[17:05] <cking> sconklin, is there any chance that you can send me some info concerning how to graph the autotest data using jenkins?
[17:05] <sconklin> cking: well, it's not working at the moment, but I can send you a description of what we have in the tools repo
[17:06] <cking> sconklin, ah, not working as in temporarily busted but will be fixed?
[17:06] <sconklin> undergoing a rewrite
[17:06] <sconklin> because it never really worked well
[17:07] <cking> ah
[17:08] <sconklin> look in the kernel-testing repo in the benchmarking subtree
[17:08] <sconklin> there's a script named make-all-charts which is run from a cron job on our jenkins server. Ignore the rsync parts.
[17:09] <sconklin> but I'll warn you, it's really ugly and doesn't scale, which is what I'm addressing in the rewrite right now
[17:10] <cking> sconklin, ok, so if I back off on my implementation will can I come back to in a week or so and plug it in to the new graphing infrastructure?
[17:10] <cking> bah, that made no sense
[17:11] <apw> sconklin, just in case you wonder where the 12 or so CVEs went over night, i have updated the quantal armadaxp to match reality
[17:11] <sconklin> apw, I did wonder, but not too much
[17:11] <sconklin> cking: yes
[17:11] <cking> sconklin, OK - well, I'm almost done on my bit, I will put it into holding position
[17:11] <sconklin> cking: and you can help me test the new structure. There's really no sense in you looking at the older
[17:12] <cking> sconklin, I'm very happy to throw new stuff in to exercise it :-)
[17:12] <sconklin> cking: start collecting your data files, and you can graph them later. Just pull the latest kernel-testing master-next, as I added some new metadata to help make it easier to filter the data files
[17:13] <jjohansen> cking: I haven't been able to find a bug for it, it was first noticed on kernel.org to be a problem and apw added a wi to add the blacklisting to the enforcer
[17:13] <sconklin> The rewrite of this is partially because I started thinking about what it would be like for someone else to use it, and realized that it was very bad
[17:14] <apw> jjohansen, cking yeah it added something big somewhere important and some other locking which sucked and made it really slow
[17:14] <cking> sconklin, ok, fair point. In that case, can you zip me an email on how I should be collecting the data (and where it ends up so I can sanity check my tests) and then I'm happy to run some tests to collect data over the next week or so.
[17:15] <cking> jjohansen, ack
[17:15] <jjohansen> cking: let me dig up some more details and I will forward them to you
[17:16] <cking> jjohansen, much appreciated, thanks!
[17:16] <sconklin> cking: ack, I'll have that to you by EOD for me
[17:17] <cking> sconklin, ta
[17:28] <rtg> bjf, what did you ultimately find was the solution for the BIOS dev name issue ?
[17:30] <bjf> rtg, cjwatson submitted a fix to resolve it. i had to add the "biosdevname" package to my pkgsel list in my preseed as a work-around
[17:30] <bjf> rtg, are you seeing issues?
[17:31] <rtg> bjf, nah, just curious. what was the bug number for that ?
[17:31] <bjf> bug 1043936
[17:31] <ubot2`> Launchpad bug 1043936 in biosdevname "Biosdevname not installed in the target after server install" [Critical,Fix released] https://launchpad.net/bugs/1043936
[17:55]  * rtg -> lunch
[18:09]  * henrix -> EOD
[19:09] <kees> jjohansen: afair, after turning on ima, if you add lots of files to a file system, you shouldn't see kernel heap space used. (that was the old bug)
[19:10] <jjohansen> kees: right, need to valid that but also no regression in other cases if we are going to SRU to precise
[19:11] <jjohansen> kees: basically I just need to hammer out a test plan with a bunch of tests, and get it going
[19:12] <jjohansen> kees: well that and get a ppa up for people who want IMA on precise for the interim
[19:14] <jjohansen> oh hrmm, ogasawara being past FF we would need to file an exception to turn on a CONFIG right?
[19:14] <ogasawara> jjohansen: not necessarily for the kernel, we don't have our kernel freeze until oct 4
[19:15] <ogasawara> jjohansen: just shoot an email to the mailing list if you need us to twiddle a config option
[19:15] <jjohansen> ogasawara: okay, so we are looking at enabling CONFIG_IMA, its currently black listed. we will want to get some get supporting tests that it isn't still causing problems before turning it on
[19:16] <jjohansen> ogasawara: so I am going to work at making sure its all good before firing of that mail
[19:16] <ogasawara> jjohansen: ack
[19:35]  * smb -> gone
[20:25] <rtg_> jsalisbury, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1045027/comments/8
[20:25] <ubot2`> Ubuntu bug 1045027 in linux "iPXE kills kvm with KVM: entry failed, hardware error 0x80000021" [Critical,Triaged]
[20:43] <bjf> rtg, i also encounter bug 1046029 sometimes
[20:43] <ubot2`> Launchpad bug 1046029 in debian-installer "Network device not configured correctly" [Undecided,New] https://launchpad.net/bugs/1046029
[21:12] <jsalisbury> rtg, thanks.  That saved allot of testing requests :-)
[21:17] <rtg_> bjf, thats gotta raise hell with your Jenkins jobs that re-provision all the time
[21:17] <bjf> rtg_: it can be problematic, though i'm only seeing it on one of the three systems
[22:14]  * rtg -> EOD
[22:35] <bjf> jjohansen: is there such a thing as a apparmor "test suite"?
[22:36] <jjohansen> bjf: yes
[22:36] <bjf> jjohansen: does QA run them?
[22:36] <jjohansen> bjf: its been integrated into qrt
[22:36] <bjf> jjohansen: ah, and do you know if they run that part of qrt?
[22:37] <bjf> jjohansen: are they part of any of the "kernel" qrt tests?
[22:37] <jjohansen> bjf: I don't know, the apparmor tests are also split, so there are userspace tests and kernel regression tests
[22:38] <jjohansen> bjf: give me a bit to find which parts of qrt trigger the kernel apparmor bits
[22:38] <jdstrand> the are not part of the test-kernel* scripts
[22:38] <bjf> jjohansen: i'd very much like to start running them as part of the kernel testing
[22:38] <jdstrand> jjohansen: test-apparmor.py
[22:38] <jjohansen> jdstrand: thanks
[22:38] <bjf> jdstrand: are they all there?
[22:39] <bjf> jdstrand: in the one place i meant
[22:39] <jdstrand> bjf: test-apparmor.py has all the different apparmor testsuites, yes. it 
[22:39] <jdstrand> skips one I think by default
[22:39]  * jdstrand looks
[22:39] <bjf> jdstrand: thanks, will take a look at it
[22:40] <jdstrand> it skips the stress tests
[22:40] <jjohansen> bjf: note test-apparmor.py is just a wrapper around the old crufty Make, and shell test scripts, there are plans to update this but it hasn't happened yet
[22:41] <bjf> jjohansen: ack, like the other qrt tests. i'm used to that.
[22:41] <jdstrand> but there is a command line argument to enable them
[22:41] <jjohansen> bjf: and you don't want the stress tests atm
[22:41] <jjohansen> bjf: well at least if you want your tests to complete
[22:42] <jdstrand> jjohansen: I think one of them completes after a long while... the parser? I forget
[22:42] <jdstrand> anyhoo, yeah, they are in there
[22:44] <jjohansen> jdstrand: well, the kernel one at one point wouldn't and some of the parser ones wouldn't either. And I have some parser ones that will take down tangerine
[23:15] <bjf> RAOF: do you have the SRU desk today?
[23:15] <RAOF> bjf: I do, yes.
[23:16] <bjf> RAOF: sweet! i have some kernel packages ready to go to -updates :-)
[23:16] <RAOF> Shoot.
[23:18] <bjf> RAOF: bug 1036553
[23:18] <ubot2`> Launchpad bug 1036553 in linux "linux: 2.6.32-42.96 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1036553
[23:18] <bjf> RAOF: bug 1036178
[23:18] <ubot2`> Launchpad bug 1036178 in linux "linux: 3.0.0-25.41 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1036178
[23:18] <bjf> RAOF: bug 1041217
[23:18] <ubot2`> Launchpad bug 1041217 in linux "linux: 3.2.0-30.48 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1041217
[23:19] <bjf> RAOF: bug 1041406
[23:19] <ubot2`> Launchpad bug 1041406 in linux-armadaxp "linux-armadaxp: 3.2.0-1607.11 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1041406
[23:19] <bjf> RAOF: that's all for now :-)
[23:19] <RAOF> Wow. All the kernels!
[23:33] <RAOF> bjf: They require the various linux-*-metas as well, don't they.
[23:33] <bjf> RAOF: yup
[23:33] <bjf> RAOF: those should all be there, ready as well
[23:33] <RAOF> They are; the bugs are in a slightly different form to when I last did the kernel release, though.
[23:34] <RAOF> They've got the -meta and -lbm task set to Invalid, which threw me a bit.
[23:34] <bjf> looking
[23:35] <bjf> RAOF: that is supposed to mean they were not an abi bump so didn't require new -meta or -lbm packages
[23:35] <RAOF> Yeah; but at least 1041217 *does* bump abi.
[23:35] <bjf> looking
[23:36] <bjf> hmmm
[23:37] <bjf> RAOF: this may be a respin so the meta tasks were set in a different bug
[23:38] <bjf> bug 1036581
[23:38] <ubot2`> Launchpad bug 1036581 in linux "linux: 3.2.0-30.47 -proposed tracker (dup-of: 1041217)" [Medium,In progress] https://launchpad.net/bugs/1036581
[23:38] <ubot2`> Launchpad bug 1041217 in linux "linux: 3.2.0-30.48 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1041217
[23:39] <RAOF> Aah, yeah. infinity left himself a note on the bug about that.
[23:39] <bjf> RAOF: ^