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