[00:01] <lool> DanaG: lol
[00:01] <lool> DanaG: Yeah, it will definitely we without NAND
[00:02] <rcn-ee> DanaG, they ubuntu is currently only targeting C4... ;)
[00:02] <DanaG> Now, if u-boot had ext4 support, that would be pure win.
[00:02] <rcn-ee> if u-boot had any extX support.. ;) (that worked)
[00:02] <lool> u-boot needs to be read from somewhere too
[00:03] <lool> rcn-ee: ISTR we're using ext2 support in the dove images, not quite sure anymore
[00:03] <lool> problem is that we still need to load u-boot from MMC I guess
[00:03] <lool> so with vfat
[00:03] <lool> because the ROM will load it
[00:03] <rcn-ee> i know what you mean, i a couple other boards (avr32, etc) that has no problems with extX partitions running mainline u-boot.. Only the beagle has issues...
[00:04] <ogra_cmpc> lool, http://paste.ubuntu.com/414595/ ... i need uboot-envtools in main and integrate it into flash-kernel-installer (for cmdline/root UUID etc), but it apparently works well already
[00:05] <Martyn> rcn-ee : Right now the bulk of the work I'm doing is getting the smooth-stone SoC supported, and trying to figure out ways of recycling as much of the ARM tree in an abstracted way to do it
[00:05] <ogra_cmpc> lool, thanks so much for poking me towards NAND
[00:05] <DanaG> oh... right, you do still need fat32.
[00:05] <DanaG> It's a chicken-and-egg problem.
[00:06] <rcn-ee> Of course Martyn, cant' wait to see what that board can actually do. ;)
[00:06] <DanaG> Can't read u-boot itself from ext4, anyway.
[00:06] <Martyn> rcn-ee : One of the big problems, at least for me, is that Grant Likely device tree patches aren't going to make it in until mid 2.6.35, even .36
[00:06] <Martyn> rcn-ee : Coming to Brussels?
[00:06] <DanaG> I wonder if you could fit u-boot in an MBR.
[00:06] <Martyn> DanaG : No.  i've tried
[00:06] <DanaG> Bummer.
[00:06] <Martyn> DanaG ; The problem is keeping it under 63 sectors (512bytes*63)
[00:07] <rcn-ee> Nope, not across the pond anytime soon, but i will be in esc san jose..
[00:07] <lool> ogra_cmpc: eh
[00:07] <ogra_cmpc> rcn-ee, thats a shame !
[00:08] <rcn-ee> DanaG, actually someone did intergrate X-loader into u-boot as a side project... can't remember how many months back on the beagleboard group...
[00:08] <ogra_cmpc> lool, i got a freeze exception until fri. btw
[00:08] <Martyn> rcn-ee : Pity .. I'm bringing a prototype of sorts
[00:08] <ogra_cmpc> for that bit at least
[00:08] <Martyn> rcn-ee : nVidia is helping :)
[00:09] <rcn-ee> what? no way! ;)
[00:09] <rcn-ee> i know they are kinda betting on the tegra platform, so it makes some sense...
[00:09] <DanaG> now, a Tegra netbook could be cool.
[00:09] <Martyn> rcn-ee : Heh .. true.  Although I feel kind of guilty being one of the reasons the tegra2 200 platform is hard to get right now
[00:10] <DanaG> I may not much like nvidia... but at least I'd probably be able to use compiz on the thing.
[00:10] <DanaG> ... as opposed to PowerVR.
[00:10] <Martyn> DanaG : I already saw four prototype 'smartbooks' based on the tegra2 .. but the 200 has some problems with Mini PCIe
[00:10] <Martyn> (weak ordering is supported, strong ordering is not, which breaks the PCI driver in linux_
[00:11] <Martyn> DanaG : Try the more exciting idea -- the potential for using CUDA
[00:11] <rcn-ee> Your just helping to get things supported before everyone starts yelling about the issues...
[00:11] <DanaG> hmm, weak ordering?
[00:11] <Martyn> DanaG : Yeah.
[00:11] <DanaG> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg02948.html
[00:11] <rcn-ee> i just want a PCI-E, then stick ati/nouveu based card into it.. ;)  the open-rd was interesting, but backordered..
[00:12]  * ogra_cmpc falls dead
[00:13] <Martyn> ogra :Sleep time?
[00:13] <Martyn> DanaG : Bingo
[00:14] <DanaG> Sucks that the Base and Client have different sets of I/O.
[00:14] <Martyn> and because the assumption is strong ordering (where the tegra2 demands weak ordering) ... we get brokenness all over the place
[00:14] <DanaG> I want a superset of both... "client" without the onboard IGP, with PCIe slot.
[00:14] <DanaG> hmm, still doesn't quite say what strong / weak ordering is.  Is it presence or lack of specific instructions?
[00:17] <rcn-ee> Oh ogra, found another device with no battery backed rtc...  The Always-innovating touchbook doesn't have a backup battery...  There's a mod on their wiki to add one...
[00:17] <Martyn> think of it as the difference between TCP and UDP
[00:18] <Martyn> TCP ensures that the order of packets is perserved and checked
[00:18] <Martyn> UDP .. ordering is -not- guaranteed or checked
[00:19] <DanaG> ah, but instead of packets, it's "things you tried to fetch from memory"?  (would have to include a sequence marker, of course.)
[00:20] <Martyn> something like that
[00:20] <Martyn> there are entire chapters in my PCI book dedicated to the subject
[00:21] <DanaG> hmm, that reminds me of something I had thought would be interesting: use a PCIe FPGA to do all sorts of stuff.
[00:21] <DanaG> Something I wanna' see: http://www.sondigo.com/sirocco/overview  -- something like that, but with 2.6 kernel.
[00:22] <DanaG> It's a c-media PCI audio chip on a Realtek Lexra MIPS CPU.
[00:22] <DanaG> Most ARM SOCs don't have surround sound.
[00:24] <Martyn> .. thinks
[00:24] <Martyn> NO ARM SoC's have surround sound yet, that I can think of
[00:24] <Martyn> I don't even think the Tegra2 is more than 2.1
[00:25] <DanaG> yeah, I realized that after I spoke / typed / pressed enter.
[00:27] <DanaG> http://landley.net/notes-2009.html
[06:03] <philo> hi
[06:04] <philo> i need a simple way to setup a virtual machine with ubuntu-arm running it... can anyone point me to some doc ?
[07:15] <ogra> philo, see topic :)
[07:31] <aaron_liuj> my board have two output hdmi and lcd ,but it's default out lcd ,how to change it to hdmi display
[07:32] <aaron_liuj> need i modify the frame buffer ?
[07:33] <amitk> aaron_liuj: what board is it?
[07:37] <aaron_liuj> arm
[07:37] <aaron_liuj> one type arm board
[07:38] <aaron_liuj> 2 output device , but default is lcd ,i want change it to hdmi tv
[07:38] <aaron_liuj> how to do that ?
[07:47] <amitk> aaron_liuj: I'm afraid we need more info than that. What processor does it use? Is it a custom board, etc..
[07:51] <aaron_liuj> tcc8900
[07:52] <aaron_liuj> but the i have he right worked hdmi driver
[07:52] <aaron_liuj> but the i have the right worked hdmi driver
[07:52] <aaron_liuj> but i don't know how to change the default output device
[07:53] <amitk> aaron_liuj: that is not an SoC that is supported by Ubuntu, so I'm not familiar with its drivers
[07:55] <aaron_liuj> i think it's vary samilar with pc have vga and hdmi port
[07:55] <aaron_liuj> i think it's very samilar with pc have vga and hdmi port
[07:55] <aaron_liuj> i think it's very samilar with pc have vga and dvi, hdmi port
[07:56] <amitk> it is probably in the framebuffer driver options somewhere
[08:21] <DanaG> telechips?
[08:21] <DanaG> hmm, my Cowon S9 has some telechips thingy of some sort.
[08:24] <amitk> never heard of them before
[08:25] <aaron_liuj> yeah from telechips
[08:27] <NCommander> aaron_liuj: ususally its a kernel command line option, or if you just care about X, you might be able to get by with just xrandr, but I can't tell you the specifics
[08:28] <NCommander> Martyn: dove has surrond sound
[08:28] <ogra> hrm, so broken_system_clock in e2fsck.conf doesnt help :(
[08:33] <saeed> hi there
[08:40] <saeed> ogra: hi
[08:40] <ogra> hey saeed
[08:41] <saeed> I would like to boot lucid on dove with console on serial
[08:41] <saeed> it would be very usefull if we can append args to bootargs of the boot.scr
[08:44] <ogra> saeed, that will breake the splash screen on all desktop installs, do you  want that ?
[08:45] <ogra> plymouth sadly breaks once a console= option is on the cmdline and wont display any splash anymore
[08:46] <saeed> ogra: what is splash sceen?
[08:47] <saeed> ok, I googled it
[08:47] <saeed> anyway, the console option will be added only for debug
[08:47] <ogra> heh, its the progressbar screen you see on boot of ubuntu desktop systems
[08:48] <saeed> also, we may add other options
[08:49] <ogra> it's a bit late to change these options, we need to talk to the release team given that final freeze was yesterday
[08:49] <ogra> how confident are you that they are 100% not causing any problems (the additional options i mean)
[08:49] <saeed> I see, please consider it for next release
[08:50] <ogra> we'll do, we can get a freeze exception but it must be a 100% bulletproof change
[08:50] <ogra> if the images get unbootable due to some cmdline option you request thats a disaster
[08:51] <saeed> ogra: I'm not looking to add permanent options to the cmdline
[08:51] <saeed> only temporary options for debugging specific issue
[08:52] <ogra> you can easily change boot.scr yourself
[08:52] <ogra> if its only for you for debugging
[08:53] <ogra> just grab it, remove the binary header, save it as boot.script and edit bootargs to your liking
[08:54] <ogra> then run: mkimage -A arm -T script -C none -n "Ubuntu boot script" -d <path to your boot.script file> /boot/boot.scr
[08:54] <ogra> its trivial
[08:54] <saeed> ok
[09:04] <nosse1> Morning everyone
[09:09] <aaron_liuj> good night all
[09:15] <lool> ogra: I think saeed was just asking for a local workaround
[09:16] <ogra> lool, yeah, i didnt get that
[09:16] <lool> saeed: What we kind of miss is some UI to offer multiple kernels and versions with options
[09:16] <lool> saeed: Could probably be done with the soft bootloader PoC, or some other bootloader like petitboot and such
[09:17] <lool> saeed: But locally you could regenerate boot.scr or break into u-boot I guess?
[09:18] <saeed> lool: I used to create my own bootcmd based on the boot.scr one, I also tried to modify the boot.scr as ogea suggested. both methods work
[09:19] <saeed> however, if the next release is comming with softbootloaded, then that will be great
[09:20] <saeed> btw, what is the status of the softloader?
[09:20] <saeed> Ncommander worked on that, right?
[09:21] <amitk> lool: atleast openmoko uses a u-boot that supports menu entries IIRC
[09:21] <lool> saeed: No it's not coming with softbootloader
[09:21] <lool> saeed: I think ogra and NCommander had a working proof of concept, but I'm not sure what prevented its wider use; for a long time kexec was badly broken
[09:22] <lool> saeed: Perhaps the kexec breakage prevented its use?  Not sure
[09:22] <lool> saeed: project name is now https://launchpad.net/mukluk
[09:22] <saeed> look: issues with kexec were fixed
[09:23] <amitk> http://wiki.openmoko.org/wiki/Booting_from_SD#Add_uboot_boot_entry
[09:23] <lool> So I cant comment in place of NCommander and ogra
[09:23] <ogra> lool, kexec broke suspend/resume on most arches we added it ...
[09:24] <ogra> i think it was withdrawn from most of our kernels again until thats better understood by the kernel guys
[09:25] <ogra> amitk, since you are affected by bug 563618, would you mind to confirm it ?
[09:25] <ubot4`> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "there is no way to tell fsck to ignore broken clocks on embedded systems (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/563618
[09:26] <ogra> else Keybuk will close it immediately again and tell me its fixed :)
[09:27] <amitk> ogra: done
[09:27] <ogra> thanks :)
[09:31]  * ogra waits for dpms to kick in so he can reproduce the DSS2 bug finally
[09:35] <nosse1> ogra, does the new ti-omap -5 cover the changes you made to the kernel yesterday?
[09:36] <nosse1> comparing to the -4 config, there doesn't seem to be anything changed related to console
[09:37] <amitk> nosse1: that isn't built yet... long backlog of arm packages just before freeze
[09:37] <amitk> https://edge.launchpad.net/ubuntu/+source/linux-ti-omap/2.6.33-500.6/+build/1692899
[09:38] <nosse1> amtik, thanks. I can extract the config from those sources
[09:38] <amitk> nosse1: use tab for my nick :)
[09:40] <nosse1> amitk, sorry. Didn't mean to offend. I've tried using the tab, but maybe this isn't a function in chatzilla
[09:40] <amitk> nosse1: none taken, just trying to point you to a (timesaving) feature. :)
[09:41] <nosse1> trust me, I have been looking... ;)
[09:44] <saeed> ogra: I'm trying to debug the hibernate issue https://bugs.launchpad.net/bugs/509006
[09:44] <ubot4`> Launchpad bug 509006 in linux-mvl-dove (Ubuntu Lucid) (and 1 other project) "[dove] hibernation failed to resume (affects: 2) (heat: 12)" [High,Confirmed]
[09:45] <saeed> I suspect that the issue is that the initramdisk mounts the root partition before doing the resume
[09:48] <lool> saeed: You can break into the initrd by passing extra args
[09:48] <lool> saeed: break=top break=bottom etc.
[09:48] <lool> saeed: if you unpack an Ubuntu initrd and grep for maybe_break, you should see all the possible break points
[09:49] <saeed> lool: thank, I'll try it
[09:49] <ogra> or look under /usr/share/initramfs-tools
[09:49] <ogra> (easier than explicitly unpacking)
[09:51] <ogra> lool, http://paste.ubuntu.com/414821/
[09:52] <ogra> lool, i have one prob left ... if you look below "Erasing Initramfs NAND space" you will notice that i use $kmtdsize (4MB) to erase the initramfs space
[09:53] <ogra> lool, the default size of that space is just to big to erase it all ... without erasing we cant write (generates IO errors) what would you recommend to use for a erase size ? i was pondering to hardcode a value somewhere
[09:54] <lool> ogra: You mean it's too slow to erase it all?
[09:54] <lool> ogra: how large is it?
[09:54] <ogra> yeah, its 2Gig
[09:54] <lool> For Kernel?
[09:54] <ogra> its the filesystem space for the rootfs originally
[09:54] <ogra> no, kernel is 4MB
[09:54] <lool> Who creates the Kernel partition?
[09:54] <ogra> the kernel
[09:55] <ogra> for a later release we need to sort that stuff in kernel
[09:55] <ogra> but for 10.04 i doubt we can
[09:55] <lool> Ok, there's a space for a rootfs and you use it for the initramfs
[09:55] <ogra> right
[09:55] <ogra> and its to big to erase it all
[09:55] <lool> ogra: Can't you change the partitions to be sensible?
[09:55] <ogra> takes 10-15min
[09:55] <ogra> no, they are set in kernel
[09:56] <lool> ogra: pointer?
[09:56] <ogra> in the omap mtd driver actually
[09:56] <ogra> lool, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-omap2/board-omap3beagle.c;h=962d377970e9bb198d410abf1ac1b418d0658341;hb=HEAD
[09:56] <lool> thanks
[09:57] <nosse1> amitk: Are there any other changes to the kernel except for config changes?
[09:57] <lool> ogra: Could you possibly use the kernel part for both, or is it two small?
[09:57] <ogra> for both ?
[09:57] <ogra> whats both ?
[09:57] <ogra> oh
[09:57] <ogra> 4MB is definately to small
[09:58] <lool> Yeah
[09:58] <lool> ogra: So I have some ideas, but first could you explain where these IO errors come fronm?
[09:59] <lool> I thought you could write whatever you like to mtdblock parts, the kernel will do the NAND flashing to 0xff for you if needed
[09:59] <ogra> lool, no idea, i get them if i write to unerased space
[09:59] <amitk> nosse1: no other changes, they'll happen after release as SRUs
[09:59] <lool> ogra: I suspect it's a bug in the offset / size you're writing
[09:59] <ogra> as soon as i zero it everything works flawless
[09:59] <ogra> i got the offset sizes from the beagle docs
[10:00] <ogra> they seem to be identical across all beagles
[10:01] <lool> ogra: I would say you should have at least 16 MiB for the initrd data
[10:01] <ogra> ok
[10:01] <lool> for safety, you could go to something higher
[10:01] <lool> like 64
[10:01] <ogra> where would you put it ?
[10:01] <lool> in the rootfs part
[10:01] <ogra> in the script (i dont use flash-kernel.conf yet and would happily not)
[10:01] <ogra> ok
[10:02] <lool> ogra: how do you load the initrd ATM?
[10:02] <ogra> nand load
[10:02] <lool> certainly *some* components needs to be made aware of the actual size we care about
[10:02] <lool> ogra: do you have control of that script?
[10:02] <nosse1> amitk: How do you generate the .config? Cat everyting together from debian.ti-omap/config ?
[10:02] <ogra> see the top part of my paste
[10:02] <ogra> line 10-26
[10:03] <ogra> it uses uboot-envtools to set the u-boot env
[10:05] <lool> ogra: yeah, so you're essentially already listing the initnrd size
[10:05] <ogra> right
[10:05] <ogra> i have to change it in both places
[10:05] <ogra> or would you suggest to parse bootcmd in flash-kernel ?
[10:05] <lool> ogra: I guess that's ok; if would be nice if you followed the usual u-boot variables
[10:05] <lool> beagleboard comes with a nice set of u-boot envs vars
[10:06] <ogra> mine doesnt anymore :P
[10:06] <ogra> after i played with the flash :)
[10:06] <lool> ogra: Well if you were to use proper vars, it would be nice to parse in flash-kernel
[10:06] <lool> e.g. (I'm not sure what exists already) initrd_nand_addr, initrd_nand_size etc.
[10:06] <lool> ogra: you can reset the values to their defaults
[10:06] <lool> resetenv or something
[10:07] <ogra> ah, right
[10:07] <lool> ogra: I suspect they don't use the rootfs as an initrd though
[10:08] <lool> sorry initramfs
[10:08] <lool> ogra: Perhaps it would be more elegant to just write what you need to write and use it as an initrd instead of initramfs?
[10:08] <ogra> right
[10:08] <ogra> there are no vars at all for initramfs usage
[10:08] <ogra> nor for initrd
[10:08] <lool> ogra: Hmm really
[10:09] <ogra> yeah
[10:09] <ogra> initrd isnt a concept on beagle
[10:09] <lool> jffs2args=setenv bootargs console=${console} ${optargs} root=/dev/mtdblock4 rw rootfstype=jffs2
[10:09] <ogra> even finding proper docs with google is painful
[10:09] <ogra> right, thats for a rootfs
[10:09] <lool> Oh it's certainly supported for sd
[10:09] <nosse1> I see you changed the HZ. Why is that?
[10:10] <ogra> nosse1, ??
[10:10] <lool> ogra: So I'd introduce a nandinitrdboot or similar which would set root=UUID=something and load some configurable megabytes of the rootfs as an initrd; I'd read that value from flash-kernel to zero it
[10:11] <ogra> ok
[10:11] <lool> You can re-use rdaddr
[10:12] <ogra> amitk, bug 563650 with kisses for you :)
[10:12] <ubot4`> Launchpad bug 563650 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "DSS2 oops when shutting down while DPMS is active (affects: 1)" [Medium,New] https://launchpad.net/bugs/563650
[10:12] <lool> I wonder whether it would be possible to point the kernel at the nand for the initramfs and unpack it in RAM
[10:12] <ogra> lool, what scares me a bit is to rely to much on uboot-envtools
[10:13] <ogra> lool, thats for 10.10 :)
[10:15]  * ogra will already be happy if he ends up with a bootable *something* on lucid beagle ... given bug 563618 and Keybuks attitude towards the prob thats not looking good atm
[10:15] <ubot4`> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "there is no way to tell fsck to ignore broken clocks on embedded systems (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/563618
[10:17] <amitk> nosse1: right, cat together all of it
[10:17] <amitk> ogra: thanks
[10:32] <NCommander> saeed: softbootloader was blocked on lack of kexec()
[10:32] <NCommander> saeed: kernel support landed too late for lucid unfortunately
[10:33] <lool> ogra: i'm glad I told you 64 MiB because the usual ubuntu config is actually 4 MiB
[10:33] <lool> *64
[10:33] <ogra> i would have gone with 16 :)
[10:33] <ogra> i dont think i have ever seen a bigger initramfs in my life
[10:34] <lool> ogra: given that the size in the kernel config is 64 MiB, that would seem a prudent value to use
[10:34] <lool> ogra: are you checking the file size before writing it?
[10:35] <ogra> not explicitly, no but thats just a copy paste job
[10:35] <lool> ogra: Make sure there's some check in place?
[10:35] <lool> quoting is a bit inconsistent in your diff too
[10:36] <ogra> check_size "Kernel" $(($kfilesize + 8 + 64)) $kmtdsize
[10:36] <ogra> like that ?
[10:36] <lool> apw: Would you be open to bumping the default ramdisk size in the dove config to 65536 instad of 4096?  :_)
[10:36] <ogra> (stolen from QNAP)
[10:36] <lool> ogra: something like that, I'm afraid I lack the specifics
[10:37] <lool> ogra: note that you're actually writing an u-boot image which is slightly bigger than the initrd
[10:37] <apw> lool, i think that is becoming the default on the other arm branches
[10:37] <ogra> lool, indeed
[10:37] <apw> i presume you mean for SRU
[10:37] <lool> apw: Yes, it's the case in pretty much all other branches, not sure why not on dove
[10:38] <lool> apw: I guess it's for $next-upload, SRU or late upload; happy either way
[10:38] <lool> apw: I would like if it's in git and I can forget about this discrepancy  :-)
[10:39] <apw> lool, as dove is in the can is there a bug as we'll need one to SRU the change
[10:45] <lool> apw: no open bug, can file one now
[10:45] <apw> lool thanks
[10:45] <apw> assign it to me
[10:49] <lool> apw: https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/563679
[10:49] <ubot4`> Launchpad bug 563679 in linux-mvl-dove (Ubuntu) "CONFIG_BLK_DEV_RAM_SIZE should be 65536 as in other kernels (affects: 1)" [Undecided,New]
[10:49] <apw> lool ta
[10:53] <saeed> NCommander: what is the current status of mukluk
[10:54] <NCommander> saeed: on hold. Will look at implementing for 10.10
[10:54] <saeed> NCommander: does the current version partialy work?
[11:09] <ogra> NCommander, what was the prob again with missing uboot-mkimage on certain dove installs ?
[11:10] <ogra> NCommander, were these d-i based or live ones ?
[11:10] <NCommander> ogra: live images, sometimes blew up due to network not being present
[11:11] <NCommander> saeed: yes, but the script ot make the config file automatically is buggy
[11:11] <ogra> NCommander, weird, i'm just looking at the redommends
[11:11] <ogra> *recommends
[11:11] <ogra> in ubiquity
[11:11] <ogra> and uboot-mkimage is definately in the list so it should be inside the livefs
[11:13] <ogra> oh
[11:13] <ogra> it was added on Fri Mar 26
[11:39] <nosse1> is there a link to the armel build queue somewhere?
[11:40] <ogra> https://edge.launchpad.net/builders
[11:44] <ogra> lool, erasing 64M is still taking more than 2min, i'll go with 16
[12:47] <ogra> asac, so looking at uboot-envtools ...
[12:47] <asac> ogra: thanks. and sorry i didnt fix it yet for you ;)
[12:47] <ogra> asac, using make clean breaks because the quilt patches that clean up Makefile are not applied
[12:48] <ogra> donty worry, i'm nearly done with all the omap stuff ... just needs that package
[12:51] <ogra> asac, so, i cant easily fix up the build system without adding my completely own Makefile debian/patches has Makefile patches that need to be applied to exec anything at all but rules calls unpatch in clean
[12:51] <ogra> i guess thats the reason for the rm commands in rules
[12:52] <ogra> asac, laso it doesnt remove source files it seems but it removes the link
[12:57] <ogra> asac, the missing config is caused because its actually a snipped from uboot, it would be configured during uboot build but the package here tries to be generic and thus ships only example configs
[15:16] <ocs> hi, which is the cheapest arm-board where ubuntu can run ?
[15:17] <rsalveti> ocs: beagleboard?
[15:17] <rsalveti> ocs: you can get it for $150
[15:18] <ocs> rsalveti: are you sure there are not cheaper ones?
[15:18] <rsalveti> ocs: if you want to run lucid, then I guess it's the cheaper one
[15:19] <ocs> rsalveti: lucid <--- ?
[15:19] <rsalveti> otherwise if you are happy with older releases, you can get an armv5 or armv6 board
[15:19] <rsalveti> ocs: ubuntu lucid, the next release
[15:21] <ocs> rsalveti: thanks
[15:23] <rsalveti> ocs: sheevaplug is cheaper ($99), but it's armv5
[15:23] <rsalveti> ocs: you can run ubuntu 9.04 or debian
[15:23] <rsalveti> or oe based distros, like angstrom
[15:25] <ocs> rsalveti: but sheevaplug doesn't have a video connector
[15:25] <ocs> right?
[15:26] <rsalveti> ocs: yep, you're right
[15:36] <ogra> rcn-ee, your /etc/e2fsck.conf works with mountall ?
[15:36] <ogra> (note that mountall doesnt use e2fsck but fsck from util-linux which doesnt respect the config file)
[17:08] <ogra> GrueMaster, did you test the d-i fix for the netinst images already ?
[17:08] <ogra> (for dove)
[17:09] <GrueMaster> Yes.  Netboot install now works.
[17:09] <ogra> with the default initrd without having to fiddle with mkimage etc ?
[17:09] <GrueMaster> I even wrote a little netboot.scr script for it that gets pulled via bootp.
[17:10] <ogra> sweet
[17:10] <GrueMaster> I used the latest images from http://ports.ubuntu.com/dists/lucid/main/installer-armel/20081029ubuntu98/images/dove/netboot/dove/ with out any modification.
[17:10] <ogra> perfect, thanks
[17:11] <GrueMaster> I'm still trying to figure out how to use the bootp protocol to send uboot commands.
[17:11] <GrueMaster> But I don't think uboot supports it.
[17:13] <ogra> probably not uboot, but kernel/initramfs should be able to read dhcp strings you send
[21:12] <Martyn> Is there a list of packages that are -not- attempted to be built on ARM?
[21:13] <armin76> libx86 :D
[21:13] <armin76> s390-tools :D
[21:22] <asac> Martyn: we have a architecture specific blacklist file yes. but dont ask me where ;)
[21:23] <asac> ogra: ^^ where is pas?
[21:38] <persia> asac: P-a-s isn't the entirety of it, really.  There's also package arch: fields.
[21:38] <asac> persia: sure
[21:38] <asac> but thats not in list form ;)
[21:39] <persia> No, my point is that such a list doesn't exist.
[21:39] <persia> And I know we attempt builds of silly stuff (e.g. libx86, wine1.2).
[21:40] <persia> Anyway, https://code.launchpad.net/~ubuntu-core-dev/packages-arch-specific/ubuntu
[21:52] <Martyn> thanks :)
[21:52] <Martyn> persia : That will do as a starting point
[21:53] <persia> Martyn: patches accepted for that, if you think there's something listed as not-for-ARM that should be for ARM.  I had to unburden a number of packages when working on the lpia port.
[21:55] <Martyn> right now, I'll take stability over coverage
[21:55] <Martyn> smooth-stone is looking over all the packages, and building a blueprint for UDS-M
[21:56] <Martyn> we're currently looking for a way to use eucalyptus either with LXC, or completely non-virtualized
[21:58] <persia> That shouldn't be hard at all.
[21:58] <persia> Just replace eucalyptus-nc with another component.
[21:59] <persia> I strongly recommend chatting with kirkland or smoser in #ubuntu-server about it: they are likely to be able to share good strategies.
[21:59] <persia> And I know at least one of them shares your timezone, which may make that easy :)
[22:00] <persia> Actually, they're both there now :)