[00:11] <GrueMaster> MrCurious: Natty uses gcc 4.5 which works.  Oneiric uses 4.6
[01:03] <MrCurious> gruemaster: ohhh, then thats not the cause of the 2x diff in usb speed between 10.10 and 11.04
[01:04] <GrueMaster> No, that is another issue.  Not sure what, but it is another issue.
[01:04] <GrueMaster> Possibly slightly related, but I don't know.
[01:04] <MrCurious> ok, ty :D
[01:04] <MrCurious> color me super-interested in that 2x speed issue
[07:41] <apw> ogra_: i hear your ti-omap4 kernel isn't good
[07:43] <apw> infinity: ^^
[07:43] <infinity> apw: You hear correctly.
[07:44] <infinity> apw: The gcc-4.6 versus USB fix isn't actually in the current kernel.
[07:44] <apw> infinity: do we know that that is the one and only patch you need in oneiric, can can you confirm that we are using the 1309 kernel in the tests you did
[07:44] <infinity> apw: (AIUI, it also affect omap3)
[07:44] <apw> infinity: i thought omap3 was out of master, and the fix was already in ... let me check
[07:44] <infinity> apw: We were testing with 1309, I can't confirm we don't need more fixes. :P
[07:45] <apw> infinity: ok then i'll pull that one over and run you up a test build, are you able to inject that to test
[07:45] <infinity> apw: Oh, I mean the bug affects omap3.  I'm not sure if it's in the current omap3 kernels.  I *know* that omap4 is broken (since I tested that myself)
[07:45] <infinity> apw: I should be asleep (have been working on that for hours), but you might get an ogra awake soon.
[07:46] <apw> infinity: i assume he has the h/w to test
[07:46] <infinity> We all should.  In theory.
[07:46] <infinity> I hope he does. :P
[07:47] <infinity> apw: Though, realistically, it can't get any MORE broken, so even a blind upload beats the current situation.  (sadly)
[07:47] <infinity> apw: Given that nearly anything of interest on the Panda is on the USB bus, a kernel with broken USB is effectively a dud.
[07:48] <apw> it is a shame we didn't notice this before the freeze
[07:48] <infinity> apw: Sorry we didn't notice this when it was uploaded, but it seems no one got around to updating -meta until very recently, so our dailies were happily using the old kernel.
[07:48] <apw> infinity: indeed, but that kernle is broken too
[07:48] <infinity> (A great argument for making sure -meta is in lockstep...)
[07:48] <apw> (apparently)
[07:49] <infinity> No, the old kernel is fine, owing to it having been built with an older toolchain, I believe.
[07:49] <infinity> (The source has the same bug, obviously, but the binaries are old enough to be unbroken)
[07:49] <apw> bah what a mess
[07:49]  * infinity nods.
[07:50] <infinity> No argument here.
[08:00] <apw> infinity: in better news omap3 out of master looks to have the fix
[08:01] <infinity> apw: Shiny.
[08:01] <apw> ogra_: poke
[08:01] <apw> infinity: if arm vendors were more open they'd not have this problem
[08:02] <ogra_> apw, gimme a sec, i dont have the recent image here
[08:20]  * infinity finally wanders off to pass out.
[08:20] <infinity> apw, ogra_: Good luck with kernels.
[08:20] <ogra_> i'm confident all will be fine :)
[08:21] <apw> ogra_: ok i am building an oneiric kernel with that one patch for you to test, i'll shout when its ready
[08:22] <ogra_> k
[08:22] <apw> ogra_: i assume we have CDs for ti-omap4, so we'll need that respun, shall i warn the release team
[08:22] <ogra_> i'll do that, dont worry
[08:25] <ogra_> argh, why did resizing get so slow
[08:29] <ogra_> grr
[08:32] <dmart> win 6
[08:38] <apw> ogra_: we simply have to start testing these images earlier.  it takes 12 hours to build, we freeze the kernel friday before the milestone and we need to be testing then
[08:39] <ogra_> yeah
[08:39] <ppisati> my mistake, i should have warned that the fix wasn't there (and was needed)
[08:39] <ogra_> we would have known if the meta would have been updated alongside
[08:39] <apw> ogra_: but we should have noticed that sooner too
[08:39] <ogra_> we simply didnt notice the availability for two weeks
[08:39] <apw> its not like the version number is a secret
[08:40] <ogra_> no, the timing was just bad i guess
[08:40] <apw> of course it was my mistake that it was missing of course
[08:40] <ogra_> during the sprint everyone was focused on spec work and didnt check the archive
[08:40] <ogra_> apw, i'm not blaming you
[08:40] <apw> having rally the week before a milestone was dumb too
[08:40] <ogra_> its as well our mistake, i usually monitor -changes for kernel and bootloader uplaods
[08:41] <apw> ogra_: i am to blame for the meta missmatch, its a delayed action and easily missed annoyingly
[08:41] <apw> yeah, i'll try and make sure i tell you as well
[08:41] <apw> so we close the loop more effectivly
[08:41] <ogra_> we should merge meta and source probably
[08:41] <ogra_> or is the separation a safety thing ?
[08:42] <apw> the separation is both a safety valve and a timing thing
[08:42] <ogra_> rebuild it every time, but only bump the deps if necessary
[08:42] <apw> as you need the master linux-libc uploaded and built before
[08:42] <apw> more obviusly needed for master where the i386 and your architecture need to be built before your kenel will install
[08:42] <ogra_> well, effectively it sits in NEW until manual intervention, -meta doesnt need linux-libc to build
[08:43] <apw> and if it won't then apt loves to deinstall all your kernels
[08:43] <apw> ogra_: well that might be true if they were in the same package
[08:43] <apw> will put that on my list to investigate
[08:43] <apw> for releases with lbm then it needs to be separate
[08:44] <apw> though i do have a plan to make it have a dep so at least it can be uploaded and will drop to depwait
[08:44] <ogra_> well, there are surely bad things to find in that idea :) its just a thought
[08:44] <ogra_> without much background research
[08:44] <apw> good thoughts indeed specially for these special arm branches
[08:44]  * apw adds some actions for that
[08:45] <apw> ppisati: i can't really blame you for this milestone, never really talked to you about what matters for us and when the critical times are
[08:47] <apw> ogra_: ok kernel to try in: http://people.canonical.com/~apw/ti-omap4-oneiric/
[08:48] <apw> ogra_: do we produce anything other than the headless images for omap4 ?
[08:52] <ogra_> headless is called server now
[08:52] <ogra_> and yes, we produce netboot and desktop too
[09:01] <ogra_> gra@panda:~$ uname -r
[09:01] <ogra_> 2.6.38-1309-omap4
[09:01] <ogra_> ogra@panda:~$ lsusb
[09:01] <ogra_> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[09:01] <ogra_> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
[09:01] <ogra_> Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
[09:01] <ogra_> Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
[09:01] <ogra_> apw, ^^^ looks good
[09:02] <ogra_> ogra@panda:~$ ping ubuntu.com
[09:02] <ogra_> PING ubuntu.com (91.189.94.156) 56(84) bytes of data.
[09:02] <ogra_> NIC is there too
[09:02] <ogra_> apw, upload away i'd say
[09:21] <apw> ogra_: seen this ever when bootstrapping an armel chroot ?
[09:21] <apw> qemu: fatal: cp15 insn ee1d6f70
[09:21] <ogra_> ouch
[09:21] <ogra_> nope, but i havent used chroots in a while
[09:22] <ogra_> looks serious though
[09:22] <ogra_> what release ?
[09:23] <apw> making chroots on lucid, specifically making an oneiric chroot
[09:24] <ogra_> well, which qemu are you using there ?
[09:24] <ogra_> the linaro backports should work afaik
[09:35] <apw> ogra_: that is a good question
[09:35] <ogra_> the shipped qemu in lucid definitely wasnt as good as the later linaro packages
[09:36] <ogra_> and iirc they provide PPA backports for all their releases
[09:37] <apw> ogra_: ok that looks like a standard qemu version number to me, any idea where this PPA is ?
[09:38] <ogra_> not really
[09:38]  * ogra_ checks 
[09:40] <ogra_> https://launchpad.net/qemu-linaro/+milestone/2011.06
[09:42] <ogra_> hmm,. no PPA
[09:42] <ogra_> https://launchpad.net/~linaro- /+archive/tools/?field.series_filter=lucid
[09:42] <ogra_> there we go
[10:08] <kunguz> what should be a proper bootcmd for X-loader to start ubuntu-arm
[12:31] <sveinse> ogra_, rsalveti: I have an issue with rootstock. It seems the diversion of /usr/sbin/invoke-rc.d isn't properly removed. Another script is trying to divert and it complains about the rootstock diversion to be in the way. However I read from the script that it does call dpkg-divert --remove --rename /usr/sbin/invoke-rc.d
[12:32] <sveinse> I even read "Removing 'local diversion of /usr/sbin/invoke-rc.d to /usr/sbin/invoke-rc.d.rootstock'" from the rootstock logs
[12:33] <sveinse> But running dpkg-divert --list on the target it still lists /usr/sbin/invoke-rc.d.rootstock as a diversion
[16:37] <phh> hey there, is it possible to access to the camera on OMAP4 from "normal" distributions, and if so, how ?
[16:37] <phh> i'm trying with openmax ducati api, jut it just won't fill my buffers
[16:45] <ogra_> phh, probably #pandaboard might be better, there are also the TI hardware guys
[16:47] <phh> bah, just when I ask i've got some progress, if i issue Flush command, it starts sending stuff to me ...
[16:49] <phh> err, or not
[16:53] <phh> yup, not.
[17:56] <montamer> Hi guys ......... I have a query, Does anyone here tested ubuntu on pandaboard? Does ubuntu supported accelerated video codecs for omap4?
[18:53] <GrueMaster> montamer: Yes.  We have a natty build for panda, and you can install the accelerated graphics package as well.
[18:53] <GrueMaster> See topic for links.