[00:51] is there a list of ftbfs for arm? [00:52] the wiki has one last updated in like november [01:14] davidm: ping [02:08] Mirell: greetings [02:52] 'allo === pwnguin_ is now known as jldugger [08:17] jldugger, http://qa.ubuntuwire.com/ftbfs/ [08:26] ogra: just finished reading the massive scrollback from yesterdays apex debugging. Impressive work! [08:27] ogra: So it seems it isn't a kernel problem? [08:27] * amitk starts to read up on apex a bit [08:32] amitk, well, upstream answered my last mail on debian arm ... where i said "hello, my kernel panics if i choose more than 5M for the ramdisk size" ... with "yes, you can use up to 8M for the ramdisk" [08:32] its not all solved yet, but i have a workaround for now [08:33] whih i intend to upload so we get working daily builds as soon as there is a kernel ... but its something we surely need to revisit [08:33] *which [08:34] ogra: re: as soon as there is a kernel? [08:34] the kernel corruption thing itself is solved ... [08:34] amitk, our endiness is wrong [08:34] *endianess [08:34] ogra: ah right, i'll get that fixed [08:34] anything else you need in the ixp4xx image for this upload besides endianness? [08:35] and if i use the kernel not swappped with devio it stops after unpacking (not sure thats related to endianess mistmatches with apex, kernel and initramfs but i suspected so [08:36] only the NIC firmware ... doing a netinstall without NIC is quite tricky ;) [08:36] and that will be required for d-i too [08:37] right, but d-i builds udebs from linux-firmware [08:37] just a matter of adding the right udeb to the netinstall image [08:37] i might have kernel changes afterwards though, i couldnt test our kernel at all yet [08:39] (i.e. i dont know how it bevhaves in an installed system ...) [08:40] lool got it to boot directly from redboot during the sprint (which is why i suspect the non booting to just be an endianess issue in d-i) but we werent able to change the cmdline in redboot as everything at that stage is readonly [08:41] amitk, did you get your serianl port to work ? [08:41] *serial [08:43] ogra: removing the solder blobs is being a problem, i've got to go and get a desoldering braid [08:44] yeah, though davidm managed to just blow it out of the holes, i had to use a pump [08:44] blowing it sounds dangerous, though he has a ton more experience than I do [17:56] hi [17:58] I have this board with an ARM, 128MB of memory, USB, ethernet, serial, VGA, audio, PS/2; I wrote all the drivers. Can I run Ubuntu on it? [18:07] sure [18:07] see the last link in the topic [18:08] well [18:08] I think my board is not a ready target [18:09] it will require the proper drivers for example [18:10] even an headless image would require my ethernet drivers [18:10] or - maybe I'm mistaken and this rootfs does not contain the kernel [18:12] right, its only the userspace [18:13] if yu have a kernel, use that, if you can push your drivers upstream to kernel.org we can fully support your board in jaunty+1 [18:45] yeah :) that would be nice [18:45] just as an information, when is likely to be the "freeze" for j+1 ? [18:48] hard to predict, the j+1 schedule will only be finalized at the next developer summit ... which is in may [18:49] jaunty releases in april ... feature freeze for jaunty is next week [18:50] feature freeze is usually the point where stuff like that needs to be in ... given that j+1 will happen in october it might be around august [18:58] yeah but it is hard by that time my drivers will be in an official kernel release [18:59] it's a lot of stuff in many subsystems [19:00] well, if you can get them into .29 or .30 we'll get them for free from upstream [19:00] then supporting your HW is a non issue, just a matter of enabling the .config [19:01] yeah [19:01] listen as a side question [19:02] openoffice is actually running on ARM? [19:02] on some HW, yes [19:02] i doubt you will get it running properly on 128M though [19:02] do you have an idea of the requirements? [19:02] it will *run* but not be fun [19:03] or an hardware that is known to run it? just as comparison with what I have here on this board [19:03] if you want to support ubuntu-desktop including firefox and openoffice your HW should have above 256M and above 500MHz [19:03] yeah :) it's a pity, I remember when I was able to run office97 on a 16MB PC :( nowadays 128MB are too little [19:03] i doubt there is any HW public yet [19:03] ah ok [19:05] http://www.notebooks.com/2009/01/07/new-generation-of-netbooks-199-and-299-eight-hour-battery-sexy-design/ [19:05] something like that will likely run ubuntu-desktop incl. openoffic fine [19:09] by the way, what about Koffice, it used to be lighter than OOo [19:09] * ogra hasnt tried any QT based stuff on arm yet [19:09] i know xubuntu and gcoffice work fine though [19:09] even on the beagleboard i have if i add some swap and a USB disk [19:10] (so that IO times are not to huge) [19:11] gcoffice = ?? I only found a german cheese office with that name :) [19:11] abiword and gnumeric [19:12] the actual so called "gnome office" [19:46] the moment you create this rootfs... what format is that? it is likely the way to mount it is with a USB key right? [21:59] alesan, its a tgz that you csn untar on any kind of partition (given it has the right size) [21:59] *can [21:59] if you use the --notarball option it will create a qemu image instead [21:59] so you can play with it in qemu-system-arm