[00:02] sakoman: hm, I guess I saw this patch some time ago, but didn't give a try [00:03] and the patch I saw upstream didn't get into linux-omap [00:03] went directly to linus tree [00:03] sakoman: but nice to know you were using it already === orbarron is now known as orbarron|OoO [00:26] rsalveti: I suppose I should have commented in the patch about how much performance improved :-) [00:27] Spiffy, it's rotated 10 degrees. [00:27] xrandr --output LVDS --transform 0.985,-0.174,0,0.174,0.985,0,0,0,1 [00:27] Watch out, save your work first, in case it crashes. === DanaG1 is now known as DanaG [03:55] cooloney: hey [03:55] cooloney: unfortunately the patch didn't fix the mem issue :-( [03:56] it seems it could be related with omap specific code, but didn't look it further [03:59] rsalveti: yeah, i saw that [04:01] rsalveti: from your comment, 'gcc: Internal error: Segmentation fault (program cc1)' [04:01] do think is it a gcc issue? [04:02] cooloney: don't think so, the system itself tuned out very unstable after I got this segfault [04:03] so probably mem corruption [04:03] that's why the segfault [04:04] rsalveti: do you think Gary's patch helps to fix the memtester issue? [04:04] rsalveti: i think we need a simple test case to easy reproduce the bug [04:06] cooloney: it seems it helped in someway, as you can now run memtester more than without the patch [04:06] but every time I tried to build the kernel and run memtester at the same time, weird things happened [04:06] maybe just memtestar but using the whole memory could trigger this issue, but didn't try [04:09] rsalveti: ok, thanks a lot for helping this [04:09] cooloney: maybe a bisect at cache maintenance lazily patches [04:09] but it's a painful job [04:09] yeah, it's painful. [04:10] any chance to test upstream 2.6.36-rc3? [04:11] don't know how is the current omap 4 upstream support [04:13] rsalveti: i saw some patches will make upstream work on ES2.0 in linux-omap mail list [04:14] cooloney: yep, saw that too, maybe with those patches you could be able to at least boot it [04:17] rsalveti: and are you using NFS for building the kernel? [04:17] cooloney: nops, usb hd [04:30] rsalveti: cool [04:48] rcn-ee: were you able to build and test the sgx modules/libraries from 3_01_00_07? [04:48] I saw that your script is still using the 3_01_00_06, but with a kernel patch from 3_01_00_07 [04:49] rsalveti, yeap, '07 only changed one source code line.. otherwise it works fine.. [04:49] rcn-ee: oh, cool [04:49] rcn-ee: the nice thing about 07 is that we can wget it! :-) [04:49] good for scripts [04:49] that's why I was thinking why weren't you using it already [04:50] yeap very good.. we still need an x86 to extract that... but with no more export license, it should be easy to untar and then create a redistributable *.deb for the repo's? [04:51] rcn-ee: that's what I'm looking for [04:51] the kernel patches will be off the tree, so we need to build them as modules [04:51] Hmm, how about the TI DSP GST stuff? [04:52] and if we're still unable to redistribute it, at least we can create a script that can generate the deb file [04:52] then the user can just install them to be able to use sgx with omap 3 [04:52] as for omap 4 is a whole different story [04:53] DanaG: I think rcn-ee did some work on it, but I still want to see the sgx working first [04:53] well, that's still so relatively new too thou... at least ti looks to be pushing that one upstream... [04:53] And too bad we only get GL ES, not GLX. [04:54] And texture_from_pixmap, most specifically. [04:54] we'll get glx for omap 4 [04:54] at least that's the plan [04:55] Spiffy. Compiz is the big thing that I use nearly 100% of the time I'm booted into Linux. [04:55] it's moving in a good direction, when i first started it was a 2-2 week delay between request and approval of the sgx drivers as they researched you.. now just a wget away.. [04:55] rcn-ee: yeah, much much better [04:55] hmm, when I requested it with a calpoly.edu e-mail address, it was approved automatically, or at least really quickly. [04:56] * DanaG goes off to violate iTunes' EULA by using it to make nuclear missiles. [04:56] * DanaG accidentally blows himself up with his own missiles. Oops. [04:56] but still didn't check the 07 bin content, huge download [04:56] * rsalveti want to check the license [04:56] well this was back when the beagle first came out, internal TI had no idea what i was talking about.. ;) [04:56] haha :-) [04:57] yeap, 512Mb download: Base libs 18Mb, Demos: 204Mb, lots of extra fluff... [04:58] Priceless? [05:00] not quite yet, maybe in 6months? ;) [05:01] can't seem to find the email, but there is one odd new bug in '06/'07 with Meego's gui.. Other than that I haven't had any reports.. [05:01] rcn-ee: hm [05:02] Oh yeah, ARM "Eagle" sounds awesome. [05:02] let me try to find it [05:02] yep :-) [05:02] I just hope they make drivers easy to install (like nvidia, or even better, fglrx). [05:02] None of this "Make" trying to "make clean" on a hard-coded dir that doesn't exist. [05:03] But with "eagle" you have 4 cores with vfp/neon.. i think 4 neon cores could kick an sgx graphics engine.. ;) [05:03] hahah :-) [05:10] hey rsalveti, been kinda wondering in the background, are you guys thinking of bumping maverick+1 to hardfp? Or going to wait to see how debian's min port goes? [05:11] rcn-ee: don't know for sure, we could discuss it on uds-n [05:11] it'd be interesting, I believe [05:11] now that debian got it, it'd also be easier [05:13] yeap, they are still jumping thru a couple hoops, but it'll be interesting to see what it does.. I finally got the dspbridge stuff working, so i'm getting that ready for 10/10. But i'm tempted to jump and try the armhf stuff. [05:14] cool [05:14] yep, me too :-) [05:15] hm, the download will take a while, not I'm getting 80k/s [05:15] going to sleep, will check it tomorrow [05:15] see ya [05:15] later... [05:20] Ah, when I tried dsp-link, the makefiles and configs were confusing. [05:21] I never did quite figure out how to set those environment variables. [05:21] Er, paths, rather. [05:21] me too... those gave me a headache.. i never got it to work outside angstrom's git tree.. [05:22] the sgx stuff was a breeze, in comparison.. ;) [05:22] I hope Linaro will make TI fix that. [05:23] I like how fglrx builds debs for you... they should strive to match that. [05:24] well the sgx stuff is way easier now, specially with putting the modules in a kernel tree: http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/files/head:/patches/sgx/ [05:25] its just builds inside a 2.6.33 - 2.6.36-rc1 kernel just fine.. [05:26] i've been playing with ti/nokia's dspbridge thou, it's in staging at this point, and it does seem to work with 2.6.35.. I'm working on packaging all the userspace lib's so you can watch videos.. [05:26] Spiffy. [05:26] Can it do encoding 640x480 h.264? [05:27] http://stackoverflow.com/questions/2893407/why-does-use-of-h264-in-sender-receiver-pipelines-introduce-just-huge-delay [05:27] Take that rtsp example, and tweak it to use TI's stuff. [05:27] i think it can.. but to be honest, i've built the dspbridge driver, got it to load the codex dll's but haven't got the video player stuff going yet.. [05:31] DanaG, here's dspbridge doing encoding on th e N900 while the beagle decodes. .;) http://felipec.wordpress.com/2009/10/13/new-project-gst-dsp-with-beagleboard-demo-image/ [05:33] Looks more like he's using N900 as a camera. [05:35] yeah, either way i need to play with my self... i know my touchbook out of the box uses dspbridge and that works great with my xvid videos.. [05:35] I think you lost an "it" there. [05:35] =รพ === zyga-gone is now known as zyga === hrw|gone is now known as hrw [08:35] morning [09:32] nice. both armel-cross-toolchain(-base) packages builds, and both are lintian free [09:40] With which arguments? -iIEv --pedantic? [09:41] with defaults. will check your [09:43] It's often worth running the longer arguments (against both source.changes and ${arch}.changes) just to see if there are any other hints available. No reason to "fix" everything, but most bears thinking about. [09:44] sure [09:44] thx for set [09:45] Just take some of them with a grain of salt. The experimental and pedantic ones especially. [09:45] sure [09:46] ok, one is clean from your set ;) [09:46] now time for next [09:50] ok, second is cleaned us much as possible [09:50] duplicated descriptions has to stay [09:51] description-synopsis-is-duplicated or description-contains-duplicated-word? [09:52] duplicate-short-description duplicate-long-description [09:52] and it cant be changed cause this is how this package works - generates packages from gcc-4.4 and gcc-4.5 [09:56] Where's the control file? [09:57] persia: http://github.com/hrw/linaro-armel-cross-toolchain/blob/armel-cross-toolchain/debian/control [10:00] hrw, Just inject the versions into the descriptions. Helps folks choose better for package managers that don't show the package names. [10:00] (yes, these exist. no, I don't know why) [10:01] persia: that would require changes to gcc-4.4/4.5 and I want to avoid it [10:02] Hrm? Why? [10:02] persia: debian/control of armel-cross-toolchain is regenerated during build [10:02] At source build time, or at binary build time? [10:02] from packages [10:02] binary [10:03] Ugh. One isn't supposed to do that, by policy, but I understand why you do. [10:03] but I have to test ver without it [10:03] One is supposed to do it at source build time, if one must. [10:03] Anyway. File a bug against the other packages. If they have the same description, that's bad in a much wider context. [10:03] And once that is fixed, it fixes your issue automatically :) [10:05] ;) [10:05] maybe after maverick [10:06] * persia prefers to file bugs early and often, and pay them no attention until later, rather than trying to keep a TODO list of bugs to file [10:09] the thing is that I do not see those duplicate descriptions as bugs [10:11] How can a user using a tool that doesn't show the package names distinguish the packages if they have the same description? [10:11] Is it not a bug that someone might install the wrong version of GCC because the tools didn't give them enough information? [10:14] I would say that such tools are buggy [10:15] Software center is buggy ? [10:15] It's the direction of the future. [10:15] User-oriented design themes, etc. [10:16] ogra_ac: maybe hard to believe but I never used it [10:16] Well, it doesn't expose package names at all [10:16] Oh, easy to believe :) Still, it's the recommended default package manager for Ubuntu Netbook and Ubuntu Desktop, so we ought cater to it's design. [10:17] heh.. pdebuild is most used command during last 2 days [11:46] ogra_: Hi. Is it necessary to "start PC card services" on Panda ? [11:46] its a default in the installer and would require hacks to avoid the call, it will immediately return anyway if there is no HW [11:47] ogra_: ok, so no issue then. [11:47] right, the UI isnt really reflecting whats happening there [11:47] ogra_: By the way, I don't know if you saw a bug I just entered to "recap" this story about my black screen after boot... [11:47] i.e. it shows the last message until a new one comes up [11:47] * vstehle feels ashamed [11:47] ogra_: Cable issue :( [11:47] yup saw it, i still have no idea [11:48] lol [11:48] i have that all the time, dont be ashamed [11:48] ogra_: But maybe you don't post it in front of thousands of launchpad "watchers" :) [11:49] dont worry, i filed ebarassing bugs too in my life :) [11:49] better to file one to much than to release with bugs :) [11:50] ogra_: I am giving a second try at "system test", now that I have network [11:50] great ! [11:50] Oh, Ubuntu One crashes... [11:51] yeah, thats filed already [11:53] Bug 628013 [11:53] ogra: Bug 628013 on http://launchpad.net/bugs/628013 is private [11:54] grmbl [11:55] Bug 628013 [11:55] Launchpad bug 628013 in ubuntuone-client (Ubuntu) "[maverick armel omap4] ubuntuone-syncdaemon crashed with ValueError in () (affects: 1) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/628013 [11:55] better :) [12:06] ogra_: Audio seems to be broken. I have kernel messages about asoc: no valid backend [12:33] ogra_: sebjan noticed you pass mem=256@0xA... instead of mem=256M@0xA... [12:34] ogra_: We end-up with 460MB total :( [13:30] morning [13:39] haha, I always remove the M from the mem argument when changing it [13:41] vstehle, i copy/pasted from ndec's mail ! [13:41] darn [13:42] ogra: I am filing a bug on LP for this. Shall I stop? [13:42] yeah, i'm fixing it right now [13:42] ogra: on 'flash-kernel' [13:42] ogra: no bug then. [13:42] would have been jasper-initramfs btw [13:43] not flash-kernel [13:43] ogra: Meanwhile, I reported a bunch of crashes [13:43] ogra: dpkg -S /boot/boot.script did not return anything so I guessed :) [13:44] ogra: I cannot launch a gnome-terminal ! [13:47] yeah boot.script is generated on first boot [13:48] well, i can launch a gnome-terminal [13:48] by just clicking on the icon [13:48] ... fix uploaded [13:48] i'll do an image rebuild as soon as its in the archive [13:48] ogra: Did you update your packages? (I did) [13:49] no, i run yesterdays image atm [13:49] ogra: I have several apps crashing in strcmp [13:49] no upgrades [13:53] https://edge.launchpad.net/ubuntu/maverick/+source/jasper-initramfs/0.19 [13:53] FYI [13:56] i dont see any uploads that could cause gnome-terminal to crash === ogra_ is now known as ogra_panda [13:58] but let me try an upgrade [13:59] ogra_panda: The "series" of bugs I reported are linked to 634855 [14:00] ogra_panda: I have some stress test running now; hopefully until next monday :) [14:00] bug 634855 [14:00] ogra_panda: Bug 634855 on http://launchpad.net/bugs/634855 is private [14:00] i cant see it as long as its private [14:00] or at least as long as you dont subscribe ubuntu-armel [14:01] ogra: I made it public [14:02] bug 634855 [14:02] Launchpad bug 634855 in eog (Ubuntu) "eog crashed with SIGSEGV in strcmp() (affects: 1) (dups: 5) (heat: 38)" [Undecided,New] https://launchpad.net/bugs/634855 [14:03] if you use a real password in the system, better subscribe ubuntu-armel in the future [14:03] the coredump can have such things in it [14:03] ogra: My password was 'vincent' but *hush*, don't tell anybody ;) [14:04] heh [14:04] just a warning :) [14:04] ogra: But ok, I'll remember. Thanks: [14:08] * ogra_panda twiddles thumbs waiting for the dist upgrade to finish [14:25] vstehle, no probs running eog after upgrade [14:26] * ogra_panda reboots to be sure [14:26] ogra: I passed the mem=256M manually, by the way [14:26] ah, i still use the default cmdline from yesterdays image [14:26] (for 1G) [14:27] ogra: Also, for what it's worth I asked for encrypted home :) [14:27] argh ! [14:27] that wont work [14:27] ogra: it does work :) [14:27] i wonder how [14:27] ogra: it was working in Prague already [14:27] since we have one partition only [14:28] ogra: it's ecryptfs now [14:28] hmm [14:28] ogra: no need for a partition [14:29] works all fine here [14:29] ogra@ogra-desktop:~$ cat /proc/cmdline [14:29] quiet splash ro elevator=noop vram=32M mem=460M@0x80000000 mem=512M@0xA0000000 root=UUID=478d7aa0-e17f-409a-84fb-82e4cde4c1c3 fixrtc [14:30] let me change that and see [14:32] ogra: I have memtester + xaos + glschool running fine now [14:32] ogra: I'll add kernel compile shortly [14:32] lweird [14:33] vstehle: with mem=256M you system should work fine [14:33] but with 512M you can't build the kernel, weeeird behaviors :-) [14:34] works all fine even with the changed cmdline [14:34] rsalveti: I run with mem=256M currently [14:34] no crashes or anything [14:34] ogra@ogra-desktop:~$ cat /proc/cmdline [14:34] quiet splash ro elevator=noop vram=32M mem=460M@0x80000000 mem=256M@0xA0000000 root=UUID=478d7aa0-e17f-409a-84fb-82e4cde4c1c3 fixrtc [14:34] cool, with this args the system should be stable [14:34] ogra@ogra-desktop:~$ free|grep Mem [14:34] Mem: 681760 325936 355824 0 9352 120928 [14:35] 700M minus vram [14:35] ogra: We are aligned [14:35] then i dont get why you get these crashes [14:35] unless the encryption plays a role here [14:36] ogra: ...or we still have some instabilities, but less frequent. Let's wait a week-end. [14:36] well, yours really looks serious, like a libc breakage [14:37] * ogra takes a break before the call [14:37] morning [15:17] jasper-initramfs [15:17] ndec, ^^ === bjf[afk] is now known as bjf === amitk is now known as amitk-afk [15:44] ndec, https://wiki.ubuntu.com/Apport/DeveloperHowTo === Ursinha is now known as Ursinha-lunch === bjf is now known as ___bjf === ___bjf is now known as _b_j_f === hrw is now known as hrw|gone === Ursinha-lunch is now known as Ursinha [18:57] who's driving the airtunes poison? [20:20] sakoman: patches applied for v2010.09-rc1 [20:22] sakoman: thanks for following it upstream === DanaG1 is now known as DanaG