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