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