[02:52] <Sp0tter> does ubuntu support the Archos 32 hardware?
[02:54] <tmzt> what is the archos 32 hardware?
[02:54] <rcn-ee> ubuntu supports the cortex a8 'architecture' of the archoes 32, you'll have to either find someone who did the kernel, or do it yourself..
[02:54] <ScottK-droid> ogra_ac: Qt finally built so FTBFS should start improving.
[02:56] <tmzt> Neko: you should be able to add a dapm without a pcm then if it's just routing
[02:56] <tmzt> nice if linux had a framework for this
[03:03] <prpplague> ogra_ac: greetings
[03:17] <rsalveti> GrueMaster: found the nm fix
[03:17] <rsalveti> ScottK-droid: cool, nice to know
[03:18] <GrueMaster> rsalveti: What was it?
[03:19] <rsalveti> GrueMaster: lack of a proper variable type: http://paste.ubuntu.com/540509/
[03:19] <rsalveti> fix is already upstream, will now open the bug following the debdiff with the fix
[03:19] <rsalveti> will also post a new deb, so you can also test
[03:20] <rsalveti> the backtrace was really really weird
[03:20] <rsalveti> inside glib, then a segv in strchr
[03:20] <GrueMaster> Wheee.
[03:20] <rsalveti> all of that because on arm the time type is 32
[03:20] <GrueMaster> heh
[03:21] <GrueMaster> Gotta love non-portable typesets
[03:21] <rsalveti> yeah
[04:08] <rsalveti> argh, takes quite a while to install everything I need to build and then build
[04:26] <rsalveti> GrueMaster: http://people.canonical.com/~rsalveti/686320/
[04:31] <rsalveti> GrueMaster: please confirm the bug and test the fix later, then I can ask people to push the fix tomorrow
[04:53] <GrueMaster> rsalveti: I'm shut down for the moment.  Will test first thing in the morning.
[05:00] <rsalveti> GrueMaster: sure, np, also going off now
[05:00] <rsalveti> see ya
[09:29] <armin76> http://www.linuxfordevices.com/c/a/News/ZT-Systems-R1801e-/
[10:32] <ogra_ac> dmart, hey
[10:32] <ogra_ac> dmart, did my comment on the bug make the issue a bit clearer ?
[11:03] <dmart> ogra_ac: hi - has that bug definitely been isolated to busybox, and do we know where/what it is ... or is that still unknown?
[11:14] <ogra_ac> dmart, NCommander traced the issue down to exec so its definitely busybox, also the fact that dropping -marm fixes it while neither klibc nor initamfs-tools changed between maverick and natty (not even a rebuild) somehow points to busysbox
[11:14] <ogra_ac> or rather the toolchain
[11:16] <dmart> ogra_ac: do you know what is being exec'd and from where?
[11:19] <ogra_ac> dmart, run-init is from /init
[11:20] <ogra_ac> run-init exposes the same error with a random error # if you dont run it from pid 1 btw
[11:21] <dmart> ogra_ac: You mean, the shell barfs on the "exec run-init" line in /init?
[11:21] <ogra_ac> either run-init does because the environment changed
[11:21] <ogra_ac> i.e. it might be that the PID doesnt get carried over properly
[11:24] <ogra_ac> its massively hard to debug, it would be better to compare exec from busybox-initramfs with and without -marm outside of an initrd
[11:25] <ogra_ac> s/either/rather/
[11:29] <dmart> ogra_ac: ok ... bit of a mystery.  I don't see any asm in busybox, so to me that suggests a compiler bug or a bug in run-init
[11:30] <ogra_ac> cant be in run-init
[11:30] <dmart> Oh yeah, you don't rebuild that
[11:30] <ogra_ac> natty and maverick initrd's are the same apart from busybox and the toolchain
[11:30] <ogra_ac> everything else involved is 100% identical
[11:31] <dmart> right...
[11:31] <ogra_ac> thats why the bug is open for gcc
[11:31] <ogra_ac> but as i said above, its very very hard to debug
[11:31] <ogra_ac> since the only debugging you could do would be to change /init
[11:32] <ogra_ac> but with every binary you inject in the exec call the PID will change from 1
[11:32] <ogra_ac> which will expose the error in any case
[11:43] <dmart> ogra_ac: gdb --attach ?
[11:46] <NCommander> dmart: bit of a problem because the debugging tools stop spitting output when the kernel panic(0s
[11:47] <NCommander> and my understanding is that since all processes are interconnected, when pid 1 goes, EVERYTHING goes
[11:48] <ogra_ac> ah, NCommander is here, I'll hand that over then and do other vacation stuff ;)
[11:48]  * NCommander goes poof
[11:48]  * ogra_ac isnt offifically here until end of year 
[11:48]  * NCommander just saw the hilight since I was talking to a friend on another channel
[11:48]  * NCommander isn't here either
[11:49] <ogra_ac> NCommander, but you will at least be in a few hours ;)
[11:49] <dmart> NCommander: the kernel panics if PID 1 dies ... possibly we could hack the kernel not to do this
[11:49] <dmart> Though there might be odd knock-on effects.
[11:49]  * ogra_ac just tries to find out when we switched to i686 by default
[11:50] <NCommander> dmart: I don't think you can, everything is a child process of PID 1
[11:50] <dmart> parent process death isn't generally fatal
[11:50] <NCommander> you might be able to debug from the kernel debugger, but then you run into nasty VM issues
[11:50] <dmart> but you will need to suppress or ignore the SIGHUPs that the child processes would get
[11:51] <dmart> None of this is easy though :/
[11:51] <NCommander> dmart: according to ogra, run-init is dependent on being PID 1
[11:51] <NCommander> ideally, the easiest way to debug is to remove that requirement
[11:52] <dmart> Might not work though ... being PID 1 is genuinely different in some ways from being any other PID, mostly to do with signal behaviour IIUC
[11:52] <ogra_ac> NCommander, not *being* only *being run by*
[11:52] <NCommander> Maybe use Userspace Linux, or something like that?
[11:53] <NCommander> ther ehas to be way to have a pseudo-PID 1, else Keybuk would have probably gone mad trying to debug upstart
[11:53] <dmart> run-init is exec'd, so it will be PID 1 also...  and run-init execs upstart, so that will be PID 1 too
[11:53] <ogra_ac> right
[11:53] <dmart> Yeah, I guess he may have some good ideas...
[12:43] <dmart> ogra_ac, NCommander: here's an approach which seems to work for debugging init:
[12:43] <dmart> ogra_ac, NCommander: http://pastebin.ubuntu.com/540609/
[12:44] <dmart> I don't have the right filesystem in front of me though
[14:23] <ScottK> NCommander: You assume he didn't.
[14:30] <ScottK> NCommander: Anything you changed for Alpha 1 due to Qt being dead you ought to be able to put back now.
[15:37] <dmart> ogra_ac: ^ did you spot that link?  Should I post it somewhere else?
[15:37] <ogra_ac> probably dump it in the bug
[15:37] <dmart> ogra_ac: oh, much scrolling ... well, here it is again, just in case:
[15:37] <dmart> ogra_ac:  http://pastebin.ubuntu.com/540609/
[15:38] <dmart> ok
[15:38] <ogra_ac> i mean the url :)
[15:38] <ogra_ac> dont expect me to work on it, i'm on vacation ;)
[15:39] <ogra_ac> NCommander, janimo or rsalveti have to help out, though in the end its likely to be a toolchain issue so i bet it will have to move over to linaro in the end
[15:39] <rsalveti> afaik NCommander is still looking at this bug
[15:40] <ogra_ac> right, but i suspect it to boild down to toolchain anyway
[15:40] <ogra_ac> which puts it into linaros realm
[15:40] <rsalveti> yeah
[15:41] <dmart> I'm curious to find out what the actual bug is ...
[15:41] <ogra_ac> gcc 4.5 :P
[15:41] <dmart> but I don't want to deprive other people of the fun of tracking it down :P
[15:41] <GrueMaster> Guys, NCommander is on vacation as well.  He won't be back until next week.
[15:43] <ogra_ac> GrueMaster, not according to the team calendar
[15:43] <rsalveti> yeah
[15:43] <GrueMaster> Just because he's an idiot and forgot to update the calendar, doesn't mean he is here.  Since he lives with me, I would know.
[15:44] <GrueMaster> about both.
[15:44] <rsalveti> hehe
[16:57] <rsalveti> GrueMaster: any chance to test the nm fix?
[16:57] <GrueMaster> on the phone brb.
[17:02] <rsalveti> k
[17:02] <hrw> have a nice rest of day
[17:04] <Sp0tter> does anyone know of ubuntu supports the hardware on the Archos 32 tablet?
[17:43] <GrueMaster> rsalveti: Finally able to work again.  I downloaded, installed, and rebooted with your network manager.  system works again.  Good find.
[17:44] <rsalveti> GrueMaster: nice, please post your results at the bug and let's try to find someone to sponsor the fix :-)
[17:44] <GrueMaster> Yep.
[17:48] <GrueMaster> You should see a flood of emails from LP.  I changed status to "In Progress, High priority, Natty-Alpha-2".
[17:49] <rsalveti> GrueMaster: ouch hehe :-) but thanks
[17:50] <GrueMaster> Just filling out the info for the release team.  Making the bug more complete.
[17:50] <rsalveti> yeah, nice
[17:52] <GrueMaster> Back to working on paperwork.
[18:22] <rsalveti> I'm impressed by the time it takes to get a kernel fix released into main
[18:22] <rsalveti> just got two notifications for testing the kernel released at proposed, and the bug was opened almost 1 month ago, with the fix included at the same day
[18:23] <GrueMaster> And it is already in proposed and tested by me two weeks ago.
[18:23] <rsalveti> yeah
[18:23] <GrueMaster> I've already raised the question on #u-kernel.
[19:10] <apachelogger> aloha
[19:10] <apachelogger> any clues where one would get powervr graphics drivers for omap3?
[19:12] <rsalveti> apachelogger: https://wiki.ubuntu.com/ARM/OMAP/Graphics
[19:12] <rsalveti> not the best one, and without a proper x11 driver, but it's there already
[19:13] <rsalveti> for omap4 the pvr stack is better, and also available from a ppa
[19:16] <apachelogger> uh
[19:16] <apachelogger> rsalveti: thanks :)
[19:54] <rbelem> fala rsalveti
[19:54] <rsalveti> rbelem: hey
[19:54] <rbelem> rsalveti, is qt compiled with gl es support?
[19:55] <rsalveti> rbelem: not yet :-)
[19:55] <rbelem> for arm?
[19:55] <rbelem> apachelogger, ^
[19:55] <rsalveti> it'll be soon
[19:55] <rsalveti> now that we got qt building fine again
[19:56]  * apachelogger has a change for that in pipeline
[19:56] <apachelogger> rbelem: http://people.ubuntu.com/~apachelogger/mobile/qt.tar.gz
[19:56] <apachelogger> binaries for testing
[19:56] <rbelem> rsalveti, what is going on about the qt neon discussion?
[19:57] <rsalveti> rbelem: still missing someone to sit and do the final work :-)
[19:57] <rsalveti> for maverick it'll be a little bit harder, as need proper backport
[19:57] <rbelem> :-)
[19:57] <rsalveti> problem is that qt takes too much time to build
[19:57] <rsalveti> any simple test turns out in days
[19:58] <rbelem> rsalveti,  and that gcc patch?
[19:58] <rbelem> rsalveti, does the arm toolchain works fine with icecc?
[19:58] <rbelem> that could speed up the builds
[19:59] <rbelem> apachelogger, hum... with gles and neon?
[19:59] <rsalveti> rbelem: https://launchpad.net/ubuntu/+source/qt4-x11/4:4.7.1-0ubuntu4/+build/2052893
[19:59] <apachelogger> rbelem: if maverick did not yet get changed to build without neon...
[20:00] <apachelogger> it is based on the most recent maverick package
[20:00] <rsalveti> rbelem: did finish fine this time
[20:00] <rbelem> cool :-)
[20:00] <rsalveti> rbelem: yeah, but I don't have lots of boards around to let them just building qt atm
[20:00] <apachelogger> rbelem: see my blog post on icecc & arm :P
[20:00] <apachelogger> qt builds in about 12 hours
[20:01] <rsalveti> yeah, half the time
[20:01] <apachelogger> if you did nt screw up and the build fails 3 times ^^
[20:01] <rbelem> apachelogger, wow :-(
[20:01]  * apachelogger notes that even on his laptop it took quite a while with -j10
[20:02] <rbelem> at work i usually use -j20 :-)
[20:02] <rsalveti> and the webkit linking part needs a lot of memory
[20:02] <rsalveti> and also takes quite a while
[20:02] <rbelem> rsalveti, xdeb works to build qt?
[20:03] <rsalveti> didn't try, but saw someone posting a but while cross building qt days ago
[20:03] <rsalveti> *bug
[20:03] <rbelem> :-/
[20:04]  * rsalveti brb, need to eat something
[20:04] <rbelem> :-)
[20:07] <apachelogger> rsalveti: well, 4.8 doesnt have webkit anymore
[20:07] <apachelogger> also I think we only need to do that stupid linking because Qt's help browser implicitly depends on its rendering in 4.7
[22:59] <Sp0tter> anyone have an Archos 32?
[23:00] <Sp0tter> been trying to find if Ubuntu will run on it
[23:00] <Sp0tter> it's omap