**** BEGIN LOGGING AT Mon Jan 04 02:59:57 2010
Jan 04 07:21:20 <lool> ssvb: Oddly, switching with another pixman and the problem goes away
Jan 04 07:21:55 <lool> cwillu_at_work told me that squeeze/sid/emdebian libpixman doesn't have the issue but lucid pixman (same source, different toolchain) does
Jan 04 07:22:40 <lool> I'm pretty sure he used the same kernel in all tests since we dont provide kernels for beagleboard on ubuntu
Jan 04 07:23:15 <lool> bizkut-offline: This is seriously annoying; you don't even answer when we ask you to stop your verbose away
Jan 04 07:59:22 <armin76> lool: :D
Jan 04 08:00:14 <ssvb> lool: don't know, maybe recompiling pixman (and xserver?) with a different toolchain just hides the bug
Jan 04 08:00:59 <ssvb> lool: but I know for sure that such problem existed with problematic kernels and it resulted in a similar looking artefacts on screen
Jan 04 08:01:30 <lool> Ok
Jan 04 08:02:04 <lool> Hmm right, I didn't think of rebuilding xserver, and it might be a bug in the kernel only triggered in specific conditions
Jan 04 08:02:47 <ssvb> lool: what version of kernel are you using by the way?
Jan 04 08:03:30 <lool> In Ubuntu we track 2.6.32 for the next release, but we don't provide beagleboard kernels; he was running a .32 IIRC
Jan 04 08:03:35 <lool> 11:14 < cwillu_at_work> Linux overo 2.6.32.1-x1.0 #1 PREEMPT Thu Dec 17  02:23:37 UTC 2009 armv7l GNU/Linux
Jan 04 08:03:43 <lool> I'm not sure from which branch
Jan 04 08:03:55 <lool> I suppose -omap, but then it could be any tree derived from that
Jan 04 08:06:02 <ssvb> I see, there is a small testcase which can be easily used to verify whether the kernel has this problem or not, I'll try to find it
Jan 04 08:06:19 <lool> Great
Jan 04 09:35:17 <ssvb> lool: here is a testcase for kernel bug: http://siarhei.siamashka.name/files/20100104/test-sighandler-vfp-corruption-bug.c
Jan 04 09:36:26 <ssvb> lool: looks like the fix did not get upstream yet (just tested it with the latest linux-omap kernel), makes sense to send some ping messages
Jan 04 09:39:00 <lool> cwillu_at_work: ^
Jan 04 09:39:13 <lool> ssvb: thanks!
Jan 04 09:53:14 * armin76 kicks NCommander 
Jan 04 09:53:30 <ssvb> lool: also just verified that these old patches still apply cleanly and fix the problem
Jan 04 09:54:28 * NCommander is beaten by armin76 
Jan 04 09:54:44 * armin76 steals NCommander's dove boards
Jan 04 09:55:01 <NCommander> armin76, :-P
Jan 04 09:55:21 <NCommander> armin76, http://www.engadget.com/2010/01/04/freescale-reveals-7-inch-smartbook-reference-design-hopes-to-se/ - just buy one of these
Jan 04 09:55:47 <armin76> NCommander: i prefer your boards *g*
Jan 04 09:56:54 <armin76> NCommander: gimme Z0!
Jan 04 09:57:05 <NCommander> armin76, I never had a Z0
Jan 04 09:57:15 <armin76> NCommander: get me one!
Jan 04 09:57:27 * NCommander thinks armin76 didn't get any ARM hardware for the holidays
Jan 04 09:57:47 * cwillu_at_work is pinged
Jan 04 09:57:50 * cwillu_at_work pokes lool 
Jan 04 09:58:26 <armin76> NCommander: there's an dove arm buildd that hasn't build something since october, gimme!
Jan 04 09:58:52 <NCommander> armin76, ?
Jan 04 09:59:31 <armin76> NCommander: give it to me if it isn't doing anything :P
Jan 04 10:00:07 * cwillu_at_work has finished reading the scrollback
Jan 04 10:02:03 * cwillu_at_work runs ssvb's test-sighandler-vfp-corruption-bug.c
Jan 04 10:02:15 <cwillu_at_work> cwillu@overo:~$ ./a.out
Jan 04 10:02:15 <cwillu_at_work> error: x=1090022160 y=1090022161 d=9434.232100
Jan 04 10:02:15 <cwillu_at_work> Aborted
Jan 04 10:03:56 <ssvb> cwillu_at_work: it's a bit messy, but demonstrates that the signal handler can corrupt floating point registers from the main thread, normally this test should run infinitely without any problems
Jan 04 10:04:16 <cwillu_at_work> ya, that run lasted all of 20 seconds
Jan 04 10:05:45 <ssvb> cwillu_at_work: for pixman it means that the signal handler responsible for input handling may corrupt NEON registers and as these are used for processing pixel data, it results in image artefacts which look as horizontal stripes
Jan 04 10:06:02 <cwillu_at_work> hmm
Jan 04 10:06:07 <cwillu_at_work> only horizontal stripes?
Jan 04 10:06:26 <cwillu_at_work> I only get 45degree stripes
Jan 04 10:07:41 <cwillu_at_work> this is upstreams 2.6.32.2 from git, with some patches applied
Jan 04 10:08:19 <cwillu_at_work> although experienced this under 2.6.32.1, only started playing with libpixman after I switched to that series, so I don't know about earlier kernels
Jan 04 10:08:37 <ssvb> cwillu_at_work: well, any kind of bad things may happen in general, also including xserver crashes on some occasions, so the bug is better to be fixed
Jan 04 10:09:13 <cwillu_at_work> do I only need that one patch, or do I also need patch 1/2?
Jan 04 10:09:40 <ssvb> they depend on each other, so both need to be applied
Jan 04 10:09:43 <cwillu_at_work> okay
Jan 04 10:12:13 <cwillu_at_work> re: input handling, that explains why it was so much worse when dragging a scroll bar than when using the mouse wheel
Jan 04 10:19:43 <cwillu_at_work> ssvb, this is only mildly related, but would you know what is required to gain any benefit from the neon routines in pixman?  Is a new cairo build also required?
Jan 04 10:20:02 <cwillu_at_work> (compiling a new kernel, will ping when it completes and I've tested it)
Jan 04 10:23:17 <ssvb> cwillu_at_work: just neon optimized pixman is enough, cairo upgrade is not required
Jan 04 10:23:53 <ssvb> cwillu_at_work: also pixman version 0.17.2 has more neon optimized functions and they are faster, git master has even more stuff
Jan 04 10:24:04 <cwillu_at_work> yep, I was compiling git master
Jan 04 10:24:08 <cwillu_at_work> among others... :p
Jan 04 10:24:23 <cwillu_at_work> should it be a dramatic improvement?
Jan 04 10:25:02 <cwillu_at_work> I'm mainly concerned with scrolling a firefox window at 1280x1024, and I haven't noticed a whole lot of difference
Jan 04 10:25:43 <ssvb> cwillu_at_work: what is the desktop color depth?
Jan 04 10:25:43 <cwillu_at_work> Which makes me inclined to think that firefox is either ignoring my efforts, or that I'm optimizing something that's only 1% of the problem anyway
Jan 04 10:25:59 <suihkulokki> ssvb: re: pixman and neon, is reading /proc/self/auxv really the best way to find out if the cpu supports neon?
Jan 04 10:26:52 <ssvb> suihkulokki: not sure about this, but it seems to work
Jan 04 10:28:05 <suihkulokki> yes, but it is a slight problem when run under qemu linux-user where that file is x86 auxv of qemu
Jan 04 10:30:16 <cwillu_at_work> ssvb, I've tried 16 and 24
Jan 04 10:30:24 <lool> suihkulokki: You can override glibc's hwcaps perspective though
Jan 04 10:30:26 <cwillu_at_work> sorry, missed the question while I was typing :p
Jan 04 10:30:41 <ssvb> suihkulokki: I see, but ARM CPUs unfortunately do not support any way to identify cpu type from userspace for the 'security reasons'
Jan 04 10:30:44 <lool> Wont help with pixman but can help with shared libs
Jan 04 10:31:32 <lool> suihkulokki: Perhaps qemu should provide an emulated /proc in some way though
Jan 04 10:31:50 <lool> Things like cpuinfo will be bogus as well
Jan 04 10:32:27 <ssvb> cwillu_at_work: firefox browser does all the rendering in 32bpp and converts the results to the desktop color format as the last step
Jan 04 10:32:32 <suihkulokki> lool: yeah, Qemu providing virtual /proc to apps running inside qemu would be the correct fix
Jan 04 10:33:31 <ssvb> cwillu_at_work: 32bpp is slow because memory bandwidth is limiting performance for most operations
Jan 04 10:33:51 <cwillu_at_work> ssvb, I was under the impression that 24 and 32bit were the same memory layout, and hence I didn't mention that I also tried 32 explicitly :p
Jan 04 10:34:19 <cwillu_at_work> ssvb, but should I expect to not see any improvement with the neon routines?
Jan 04 10:35:50 <cwillu_at_work> <cwillu_at_work> my kingdom for a firefox that uses 16bpp internally :(
Jan 04 10:36:04 <cwillu_at_work> ^^ is that basically the answer?
Jan 04 10:37:09 <cwillu_at_work> and if that's the case, would there ever be any chance of ubuntu's armel firefox getting patched?
Jan 04 10:42:57 <ssvb> cwillu_at_work: profiling scrolling in firefox 3.6 beta 5 looks more or less like this for me: http://pastebin.com/m669d1f7f
Jan 04 10:43:18 <ssvb> cwillu_at_work: looks like it is already 16bpp friendly
Jan 04 10:43:46 <cwillu_at_work> ssvb, as of 3.6?
Jan 04 10:44:31 <ssvb> cwillu_at_work: don't know, I just remember that this was not the case for firefox 3.0 and I had a simple patch for it
Jan 04 10:44:48 <cwillu_at_work> I'm on 3.5 right now, I'll install 3.6 and see if that improves things
Jan 04 10:45:10 <cwillu_at_work> ssvb, or do I just need to adjust my expectations?
Jan 04 10:45:22 <cwillu_at_work> i.e., is it fluid for you?
Jan 04 10:45:33 <ssvb> cwillu_at_work: but still arora browser is much faster than firefox for scrolling
Jan 04 10:46:58 <cwillu_at_work> I'm fairly reliant on a streamable xmlhttprequest in the browser, which is something of a gecko only thing
Jan 04 10:47:46 <ogra> suihkulokki, shouldnt that be possible through containers ?
Jan 04 11:00:55 <ssvb> cwillu_at_work: disregard the previous oprofile report, appears that for scrolling distribution of cpu time between graphics output and browser engine overhead heavily depends on how fast you are scrolling the page
Jan 04 11:01:55 <cwillu_at_work> rm /tmp/ssvb/hard_data
Jan 04 11:02:11 <ssvb> cwillu_at_work: this is a comparison of firefox vs. arara for scrolling with arrow down key pressed, firefox: http://pastebin.com/m6f334785 arora: http://pastebin.com/m9f98ed2
Jan 04 11:02:58 <ssvb> cwillu_at_work: arora feels much faster and it also spends almost half of the time in pixman, which firefox has a lot of other overhead
Jan 04 11:03:18 <ssvb> s/which/while
Jan 04 11:04:02 <cwillu_at_work> kernel just finished building, installing and retesting
Jan 04 11:04:59 <ssvb> cwillu_at_work: basically these profile reports show that arora benefits from pixman optimizations a lot more and the effect is much more easily visible
Jan 04 11:05:13 <ssvb> cwillu_at_work: great, let me know about the results
Jan 04 11:17:04 <cwillu_at_work> just rebooting now (wanted to update some other stuff at the same time, nothing like mixing experiments to save time :p)
Jan 04 11:19:04 <cwillu_at_work> for no particularly good reason, I've still got it booting into a 32bit framebuffer; if I understand you correctly, there's still a benefit to using 16, correct?
Jan 04 11:19:18 <cwillu_at_work> (running the test now)
Jan 04 11:21:06 <cwillu_at_work> hasn't stopped yet
Jan 04 11:21:59 <cwillu_at_work> unsurprisingly, scrolling is slow as hell while its running :p
Jan 04 11:22:10 <ssvb> cwillu_at_work: 32bit framebuffer is slower because there is more data to process, also display refresh steals some of the memory bandwidth
Jan 04 11:22:19 <ssvb> cwillu_at_work: what is your screen resolution?
Jan 04 11:22:27 <cwillu_at_work> ssvb, 1280x1024 :p
Jan 04 11:22:58 <ssvb> cwillu_at_work: ok, same here
Jan 04 11:23:02 <cwillu_at_work> the sigalarm testcase looks good, hasn't crashed yet
Jan 04 11:23:22 <cwillu_at_work> ssvb, with an otherwise idle cpu, is firefox smooth on your hardware?
Jan 04 11:23:31 <cwillu_at_work> I get about 3 frames per second
Jan 04 11:23:41 <cwillu_at_work> during full-screen scrolling
Jan 04 11:23:59 <ssvb> cwillu_at_work: it is *much* better for me, probably at least 10 frames per second
Jan 04 11:24:35 <ssvb> cwillu_at_work: but it is subjective impression, I did not run tests with camera
Jan 04 11:24:54 <cwillu_at_work> ssvb, 10 frames is just short of fluid, but still acceptable
Jan 04 11:25:39 <cwillu_at_work> ssvb, would be able to compare against ff-3.5 would you?
Jan 04 11:26:09 <ssvb> cwillu_at_work: it would take time to build ff-3.5
Jan 04 11:26:28 <cwillu_at_work> no apt-get? :p
Jan 04 11:26:48 <cwillu_at_work> rebooting under 16bpp
Jan 04 11:28:27 <ssvb> brb
Jan 04 13:33:33 <cwillu_at_work> <3
Jan 04 13:41:49 <ssvb> cwillu_at_work: any news?
Jan 04 13:42:39 <cwillu_at_work> performance seems to be respectable for a smaller scrolling region, I think I need to do some a/b tests to prove that they're actually better though
Jan 04 13:43:41 <cwillu_at_work> the glitching is definitely fixed by that patch, I've got it sent to my upstream, who grumbled about Russel being up to his usual self such that they were never applied
Jan 04 13:44:05 <cwillu_at_work> oh, hi rcn-ee, you joined :)
Jan 04 13:46:13 <rcn-ee> hey cwillu_at_work, so did the patches help with pixman? i haven't been able to test them myself..
Jan 04 13:46:34 <cwillu_at_work> rcn-ee, yes, I actually sent them after I had verified that they worked this time :)
Jan 04 16:33:37 * bizkut is away (i am away now)
Jan 04 16:34:28 * armin76 rofls
Jan 04 16:35:08 <armin76> ah, too bad lool is not here :D
Jan 04 18:48:46 <asac> ogra: you said you had a fix for apex?
Jan 04 18:49:52 <asac> http://launchpadlibrarian.net/36670366/buildlog_ubuntu-lucid-armel.libgd2_2.0.36~rc1~dfsg-3.1ubuntu1_FAILEDTOBUILD.txt.gz
Jan 04 18:49:56 <asac> http://launchpadlibrarian.net/36947837/buildlog_ubuntu-lucid-armel.libgphoto2_2.4.7-0ubuntu1_FAILEDTOBUILD.txt.gz
Jan 04 18:50:20 <asac> NCommander: you have buildd powers?
Jan 04 18:50:30 <asac> e.g. can you give back with good prio?
Jan 04 18:50:47 <asac> last build failure might be just fixed?
Jan 04 18:51:14 <asac> hmm libtool still ftbfs
Jan 04 18:51:51 * asac kicks off a build
Jan 04 19:00:35 <NCommander> asac, yeah, I can do that
Jan 04 19:00:42 <NCommander> asac, which package needs a nudge
Jan 04 19:04:21 <armin76> NCommander: nageia is the buildd that doesn't do anything :)
Jan 04 19:09:20 <asac> NCommander: nevermind. thought libtool wasnt retried
Jan 04 19:11:13 <asac> NCommander: dove images broken/not booting? or just test builds?
Jan 04 19:11:44 <NCommander> asac, the issue was that I didn't notice that we haven't had an alternate build in almost a month. cjwatson looking at antimony to see what went wrong
Jan 04 19:12:00 <ogra> asac, http://paste.ubuntu.com/351393/
Jan 04 19:12:12 <ogra> (it doesnt respect CFLAGS)
Jan 04 19:12:50 <ogra> but that only fixes the initial build failure, at the end it fails with a cast error in link.cc
Jan 04 19:14:04 <ogra> well, "link.cc:236: error: invalid conversion from 'const char*' to 'char*'"
Jan 04 19:14:13 <ogra> anyway, off again
Jan 04 19:15:28 <asac> ogra: what context?
Jan 04 19:15:44 <ogra> apex
Jan 04 19:16:12 <ogra> you asked for my apex fix
Jan 04 19:16:12 <asac> ogra: kk
Jan 04 19:16:14 <asac> i can check
Jan 04 19:17:26 <asac> ogra: if still there ... why -marm? is that a workaround or the right fix?
Jan 04 19:18:05 <ogra> apex is a bootloader for armv5
Jan 04 19:18:12 <asac> oh ;)
Jan 04 19:18:13 <ogra> and doesnt have any thumb support
Jan 04 19:18:17 <asac> yeah
Jan 04 19:18:18 <asac> makes sense
Jan 04 19:18:29 <asac> ogra: why is it in main?
Jan 04 19:18:40 <ogra> it is used for the nslu2
Jan 04 19:18:56 <ogra> that was our first supported armel arch before wer had any HW
Jan 04 19:19:09 <asac> guess we dont support it anymore?
Jan 04 19:19:16 <asac> e.g. we should unseed/demote it ;)
Jan 04 19:19:18 <ogra> it can happily go to universe, but i feel bad if i demote it in that state
Jan 04 19:19:25 <asac> sure
Jan 04 19:19:27 <asac> should be fixed
Jan 04 19:19:39 <ogra> yeah ... would feel like dumping trash on the MOTU
Jan 04 19:19:43 <asac> ogra: do you know if its seeded or why it didnt get demoted in karmic?
Jan 04 19:19:55 <asac> we want to fix all universe armel only failures too ;)
Jan 04 19:20:06 <asac> just that we start in main as its on top of that webpage ;)
Jan 04 19:20:34 <ogra> it didnt ftbfs and nobody had it on the radar
Jan 04 19:20:50 <ogra> probably my fault since i cared for it in jaunty and didnt look after it later
Jan 04 19:21:01 <asac> ogra: well. but afaik it shows up in component-mismatches unless its pulled in thorugh some mechanism
Jan 04 19:21:10 <asac> just wnat to understand what is that ;)
Jan 04 19:21:13 <asac> but no hurry
Jan 04 19:22:04 <ogra> i think its just seeded in supported
Jan 04 19:22:18 <ogra> that makes it not show up on the mistmatches page
Jan 04 19:28:09 <asac> dyfet: checked chrome?
Jan 04 19:28:17 <asac> kk
Jan 04 19:29:35 <dyfet> asac: not extensivily but it works
Jan 04 19:30:15 <dyfet> asac: and feels fast(er)...
Jan 04 19:30:37 <dyfet> or did you mean chromeos rather than chromium browser?
Jan 04 19:30:56 <asac> nope
Jan 04 19:30:59 <asac> our packages
Jan 04 19:31:00 <asac> good
Jan 04 19:31:07 <armin76> thanks to me *g*
Jan 04 19:36:35 <dyfet> asac: since it imports, I dumped my mozilla directory onto the box and let it try to import my bookmarks and passwords, it did not seem to import my passwords entirely though...
Jan 04 19:38:08 <asac> dyfet: entirely? but parts?
Jan 04 19:38:15 <dyfet> yes
Jan 04 19:38:27 <asac> dyfet: any pattern what got imported and what not?
Jan 04 19:39:04 <asac> maybe compare what you see in show passwords in ffox and chromium
Jan 04 19:39:09 <dyfet> I am not sure, but they were all form based, and it happened to be one site it only filled the email/login id, not the password field
Jan 04 19:39:26 <dyfet> but again I did not go through very many sites with it yet
Jan 04 19:41:07 <asac> ok. if in doubt i would start comparing the show passwords dialog in preferences of firefox/chrome
Jan 04 19:41:18 <asac> maybe its a bug about detecting password/input fields
Jan 04 19:41:20 <asac> or something
Jan 04 19:43:02 <dyfet> asac: it feels like there is more in my firefox saved passwords...in fact, there is some I can already confirm are missing
Jan 04 19:43:09 <asac> JamieBennett: there still?
Jan 04 19:43:24 <JamieBennett> asac: yes
Jan 04 19:43:52 <asac> JamieBennett: someone claimed that n.b.l-efl isnt localized ... e.g. like the applications and categories etc.
Jan 04 19:43:52 <dyfet> asac: never mind, I found the ones I thought were missing :)
Jan 04 19:44:02 <asac> good :)
Jan 04 19:44:23 <asac> JamieBennett: can you confirm that thats the case in our lucid build?
Jan 04 19:44:35 <JamieBennett> asac: ummm, not sure, not something I've looked into but I can check
Jan 04 19:44:42 <asac> that would be great
Jan 04 19:45:23 <asac> JamieBennett: how do one best try the launcher? does it just show up as a session variant in gdm?
Jan 04 19:45:46 <JamieBennett> When I installed it I just ran it from the command line
Jan 04 19:48:37 <JamieBennett> asac: It seems that it is localized, most strings come from the .desktop. lfelipe has tested and can confirm along with k-s
Jan 04 19:50:29 <asac> JamieBennett: ok. is sound recorder localized?
Jan 04 19:51:06 <asac> like in chinese?
Jan 04 19:51:12 <JamieBennett> no idea ;)
Jan 04 19:51:17 <JamieBennett> I use neither :D
Jan 04 19:52:17 <asac> JamieBennett: so you say you confirmed it by starting in a different language?
Jan 04 19:52:22 <asac> (on your own?)
Jan 04 19:53:36 <JamieBennett> asac: I confirmed it by asking the developer, I can play around with the local install I have if you need that but lfelipe says he can provide up-to-date screenshots for anything we need
Jan 04 19:53:50 <JamieBennett> k-s also confirmed
Jan 04 19:56:17 <asac> confirmed by running or by thinking ?
Jan 04 19:56:29 <asac> i am find if they say they run lucid packages and all is there
Jan 04 19:56:36 <asac> its just that we got a report about this ;)
Jan 04 19:56:45 <asac> s/find/fine/
Jan 04 19:57:05 <asac> so developers saying "it should work" ... might not be right approach ;)
Jan 04 19:59:58 <cwillu_at_work> I find your lack of faith disturbing
Jan 04 20:00:33 <asac> faith?
Jan 04 20:00:42 <cwillu_at_work> "it should work"
Jan 04 20:00:53 <cwillu_at_work> therefore:  it should work.
Jan 04 20:01:10 <cwillu_at_work> (I'm done now :p)
Jan 04 20:01:12 <asac> yes. but if there is a complain about it not working, its ok to double check :)
Jan 04 20:08:12 <JamieBennett> I don't have a lucid desktop install at the moment, I'll set one up (its on the todo list for today anyway)
Jan 04 20:10:11 <asac> JamieBennett: no need to if you dont have the infrastructure to check. just thought you had all in place
Jan 04 20:10:51 <JamieBennett> asac: not in a Lucid environment yet, something I will fix tonight
Jan 04 20:11:53 <asac> hehe
Jan 04 20:11:59 <asac> i should upgrade too
Jan 04 20:34:12 <asac> e.g. ~end of jan
Jan 04 20:41:02 * bizkut is away (i am away now)
Jan 04 20:41:33 <asac> bad away messages ;)
Jan 04 20:41:40 <asac> dyfet: so did you check the moblin media player?
Jan 04 20:41:56 <armin76> haha
Jan 04 20:42:01 <armin76> where's lool!
Jan 04 20:42:05 <armin76> !seen lool
Jan 04 20:42:05 <ubot4> I have no seen command
Jan 04 20:42:13 <asac> armin76: he left this channel
Jan 04 20:42:13 <armin76> bah, useless bot
Jan 04 20:42:37 <armin76> well, he just dissapeared in a net split :)
Jan 04 20:42:58 <asac> yes.... so he left the channel
Jan 04 20:42:59 <asac> because whereever i am is the main channel :-P
Jan 04 20:43:36 <asac> armin76: so did you finally manage to get something usable wrt chromium?
Jan 04 20:43:56 <armin76> asac: nah, segfault when building v8
Jan 04 20:44:13 <armin76> i'll try building on my armv7 board, but i'm busy building other stuff
Jan 04 20:44:20 <armin76> thats what happens when you only have one board :)
Jan 04 20:45:13 <armin76> could be that either something is broken or that doesn't build on armv5te
Jan 04 20:45:59 <armin76> asac: build it on jaunty :)
Jan 04 20:49:55 <NCommander> asac, I thought we had a working chromium on ARM ...
Jan 04 20:51:16 <asac> NCommander: we have ... armin76 doesnt
Jan 04 20:51:45 <armin76> :D
Jan 04 20:53:22 <armin76> NCommander: he's using an ugly patch though!
Jan 04 20:53:47 <NCommander> armin76, ?
Jan 04 20:54:07 <armin76> NCommander: asac is using an ugly patch to make it work :)
Jan 04 20:54:23 <armin76> s/work/build
Jan 04 20:55:28 <asac> hey. i have the right one ... just need to check
Jan 04 20:59:43 <mturquette> could someone point me to the apt repositories for the dove and babbage boards?
Jan 04 21:00:51 * armin76 points to asac and NCommander 
Jan 04 21:01:11 <armin76> NCommander: btw meet mturquette, he wants ubuntu rocking on omap
Jan 04 21:01:28 <NCommander> mturquette, its just the normal ports repo for bost
Jan 04 21:02:22 <asac> mturquette: http://ports.ubuntu.com/ubuntu-ports/
Jan 04 21:02:36 <asac> deb http://ports.ubuntu.com/ubuntu-ports/ lucid main restricted
Jan 04 21:02:36 <asac> deb-src http://archive.ubuntu.com/ubuntu lucid main restricted
Jan 04 21:02:39 <asac> etc
Jan 04 21:03:50 <mturquette> ah, makes sense.  thanks NCommander / asac.
Jan 04 21:04:04 <armin76> mturquette: yw :)
**** BEGIN LOGGING AT Tue Jan 05 01:02:38 2010
**** ENDING LOGGING AT Tue Jan 05 02:59:56 2010