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