[00:51] <pwnguin> is there a list of ftbfs for arm?
[00:52] <pwnguin> the wiki has one last updated in like november
[01:14] <prpplague> davidm: ping
[02:08] <prpplague> Mirell: greetings
[02:52] <Mirell> 'allo
[08:17] <ogra> jldugger, http://qa.ubuntuwire.com/ftbfs/
[08:26] <amitk> ogra: just finished reading the massive scrollback from yesterdays apex debugging. Impressive work!
[08:27] <amitk> ogra: So it seems it isn't a kernel problem?
[08:27]  * amitk starts to read up on apex a bit
[08:32] <ogra> 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] <ogra> its not all solved yet, but i have a workaround for now
[08:33] <ogra> 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] <ogra> *which
[08:34] <amitk> ogra: re: as soon as there is a kernel?
[08:34] <ogra> the kernel corruption thing itself is solved ...
[08:34] <ogra> amitk, our endiness is wrong
[08:34] <ogra> *endianess
[08:34] <amitk> ogra: ah right, i'll get that fixed
[08:34] <amitk> anything else you need in the ixp4xx image for this upload besides endianness?
[08:35] <ogra> 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] <ogra> only the NIC firmware ... doing a netinstall without NIC is quite tricky ;)
[08:36] <amitk> and that will be required for d-i too
[08:37] <ogra> right, but d-i builds udebs from linux-firmware
[08:37] <ogra> just a matter of adding the right udeb to the netinstall image
[08:37] <ogra> i might have kernel changes afterwards though, i couldnt test our kernel at all yet
[08:39] <ogra> (i.e. i dont know how it bevhaves in an installed system ...)
[08:40] <ogra> 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] <ogra> amitk, did you get your serianl port to work ?
[08:41] <ogra> *serial
[08:43] <amitk> ogra: removing the solder blobs is being a problem, i've got to go and get a desoldering braid
[08:44] <ogra> yeah, though davidm managed to just blow it out of the holes, i had to use a pump
[08:44] <amitk> blowing it sounds dangerous, though he has a ton more experience than I do
[17:56] <alesan> hi
[17:58] <alesan> 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] <ogra> sure
[18:07] <ogra> see the last link in the topic
[18:08] <alesan> well
[18:08] <alesan> I think my board is not a ready target
[18:09] <alesan> it will require the proper drivers for example
[18:10] <alesan> even an headless image would require my ethernet drivers
[18:10] <alesan> or - maybe I'm mistaken and this rootfs does not contain the kernel
[18:12] <ogra> right, its only the userspace
[18:13] <ogra> 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] <alesan> yeah :) that would be nice
[18:45] <alesan> just as an information, when is likely to be the "freeze" for j+1 ?
[18:48] <ogra> hard to predict, the j+1 schedule will only be finalized at the next developer summit ... which is in may
[18:49] <ogra> jaunty releases in april ... feature freeze for jaunty is next week
[18:50] <ogra> 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] <alesan> yeah but it is hard by that time my drivers will be in an official kernel release
[18:59] <alesan> it's a lot of stuff in many subsystems
[19:00] <ogra> well, if you can get them into .29 or .30 we'll get them for free from upstream
[19:00] <ogra> then supporting your HW is a non issue, just a matter of enabling the .config
[19:01] <alesan> yeah
[19:01] <alesan> listen as a side question
[19:02] <alesan> openoffice is actually running on ARM?
[19:02] <ogra> on some HW, yes
[19:02] <ogra> i doubt you will get it running properly on 128M though
[19:02] <alesan> do you have an idea of the requirements?
[19:02] <ogra> it will *run* but not be fun
[19:03] <alesan> or an hardware that is known to run it? just as comparison with what I have here on this board
[19:03] <ogra> if you want to support ubuntu-desktop including firefox and openoffice your HW should have above 256M and above 500MHz
[19:03] <alesan> 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] <ogra> i doubt there is any HW public yet
[19:03] <alesan> ah ok
[19:05] <ogra> http://www.notebooks.com/2009/01/07/new-generation-of-netbooks-199-and-299-eight-hour-battery-sexy-design/
[19:05] <ogra> something like that will likely run ubuntu-desktop incl. openoffic fine
[19:09] <alesan> 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] <ogra> i know xubuntu and gcoffice work fine though
[19:09] <ogra> even on the beagleboard i have if i add some swap and a USB disk
[19:10] <ogra> (so that IO times are not to huge)
[19:11] <alesan> gcoffice = ?? I only found a german cheese office with that name :)
[19:11] <ogra> abiword and gnumeric
[19:12] <ogra> the actual so called "gnome office"
[19:46] <alesan> 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] <ogra> alesan, its a tgz that you csn untar on any kind of partition (given it has the right size)
[21:59] <ogra> *can
[21:59] <ogra> if you use the --notarball option it will create a qemu image instead
[21:59] <ogra> so you can play with it in qemu-system-arm