[06:57] <DanaG> http://pastebin.com/BFjBG4Ms
[06:57] <DanaG> vlc segfaults.
[06:59] <DanaG> er, sorry for the long command line. =þ
[07:00] <DanaG> interesting... mplayer is UNAVAILABLE
[07:07] <DanaG> alsaplayer works, though.  once I add myself to "audio" group.
[09:10] <asac> hi folks
[09:13]  * ogra gets more coffee
[09:13] <ogra> morning asac
[09:14] <ogra> grmbl ... /me curses having to port uboot patches to redboot ...
[09:26] <ogra> heh, fun ... the change i should revert in redboot-imx doesnt seem to exist in our version at all
[09:30] <asac> hi ogra
[09:34] <nosse1> My company are about to make a product based on TI AM3517 (ARM Cortex-A8) and we're going to run linux. We are considering putting Debian or Ubuntu on it because we want a package system/distro.
[09:35] <nosse1> I forgot to say that I have a TI AM3517 ZOOM development kit
[09:38] <nosse1> I have to admit that I'm quite new to Ubuntu build-system, so you'll have to excuse me for stuptid questions
[09:40] <amitk> nosse1: welcome
[09:40] <nosse1> The first one is linked to the choice of distro: When I have a Cortex-A8, wouldn't it then be most efficient (space and cpu) to use binaries for ARMv7? Which would implicate Lucid right?
[09:40] <amitk> we've just started supporting OMAP3 kernels in the next release of Ubuntu
[09:41] <amitk> nosse1: Lucid is guilty as charged
[09:43] <nosse1> I started rootstock, and when it spawns qemu, it locks up my CPU at 100%. Is this familiar?
[09:44] <amitk> ogra <--- blame him
[09:45] <nosse1> I have no kind of feedback, so I don
[09:45] <nosse1> ...don't know if it has locked up or doing something sensible...
[09:46] <nosse1> (I'm running amd64 Karmic, and I've seen apps not working because I'm running 64-bit. Don't know if it's it, though)
[09:47] <amitk> no, i use rootstock on 64-bit successfully
[09:48] <nosse1> BTW: Are there a seed for ubuntu which is even more minimal than ubuntu-minimal? There's a lot of apps in minimal which is not applicable in my embedded target
[09:50] <asac> nosse1: yes, the CPU issue is known
[09:50] <asac> e.g. for qemu
[09:50] <asac> investigation ongoing
[09:50] <asac> seems its triggered by apt
[09:50] <asac> or rather dpkg somehow
[09:50] <nosse1> asac: But is it dead or processing something?
[09:51] <nosse1> asac: Can I cat into its output somewhere?
[09:52] <asac> nosse1: its dead. we think its qemu being broken
[09:52] <asac> ogra: why is the bug not filed against rootstock nor qemu-kvm?
[09:53] <nosse1> asac: Thanks
[09:54] <asac> its bug 532733
[09:54] <ubot4> Launchpad bug 532733 in qemu-kvm (Ubuntu) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 1)" [Medium,Incomplete] https://launchpad.net/bugs/532733
[09:54] <asac> nosse1: ^
[09:57] <nosse1> I running Karmic on my host. Would it (not for this specific thing, but generally) be better to run lucid?
[09:57] <asac> host system seems to make no difference afaict
[09:58] <asac> its lucid vm that causes this
[09:59] <nosse1> So when I'm using rootstock it also pulls down a lucid vm? I'm also pulling ubuntu-minimal and not ubuntu-netbook as noted in the bug report
[09:59] <asac> interesting
[09:59] <asac> but you are installing lucid?
[09:59] <nosse1> yes
[09:59] <asac> e.g. in the vm?
[09:59] <asac> i suspect this to be a racy thing
[09:59] <asac> the biggere the task is the more likely you hit it
[09:59] <asac> for us ubuntu-minimal works usually, but netbook triggeres this
[10:00] <asac> but i dontsee why ubuntu-minimal wouldnt cause this for some
[10:00] <nosse1> I can probably strace it, but I'll have to leave for a meeting first...
[10:00] <asac> what are your host specs?
[10:00] <asac> e.g. what system is this running on?
[10:00] <amitk> wouldn't it depend on the system specs too?
[10:00] <amitk> aah, exactly
[10:00] <nosse1> Ubuntu Karmic amd64
[10:00] <amitk> nosse1: your HW spec
[10:00] <asac> well. cpu mem etc.
[10:01] <asac> maybe also disk speed etc.
[10:01] <nosse1> Where can I find disk speed?
[10:02] <asac> hdparams?
[10:02] <asac> hdparm ;)
[10:02] <nosse1> Intel C2Duo T9900, 3.06GHz, 8Gb RAM, Disk: 101MB/sec
[10:02] <asac> well, but you could say: 5400 / 7200 / SSD etc.
[10:03] <nosse1> 7200 for my case
[10:03] <nosse1> I'm sorry, but I have to leave. I'll be back. Thanks guys
[10:03] <asac> yeah. so from our findings it did go away if you slow down the system, so maybe your system is faster than ours (at least than mine it is)
[10:04] <asac> so makes some sense that you see it earlier
[10:13] <asac> ogra: your instructions dont work
[10:13] <asac> e.g. the saved qemu image isnt good
[10:13] <asac> getting unable to mount rootfs
[10:13] <asac> sure root=/dev/sda?
[10:13] <asac> I: Mounting temporary Image
[10:13] <asac> I: ARM rootfs created as /tmp/qemu/armel-rootfs-201003181055.tgz
[10:13] <asac> I: Qemu image saved as /tmp/qemu/qemu-armel-201003181055.img
[10:14] <asac> i use that img
[10:14] <asac> ogra: ^^
[10:18] <asac> ok manually creating .img works it seems
[10:18] <asac> why is the kept img broken?
[10:24] <asac> hmm
[10:24] <asac> "When no option is specified QEMU uses a non privileged user mode network stack that gives the emulated machine access to the world. "
[10:24] <asac> that doesnt work for me
[10:24] <asac> ogra: ^^
[10:24] <asac> i can get an ip with dhclient
[10:24] <asac> but not ping out
[10:24] <asac> or wget
[10:25] <lool> asac: ping is special though
[10:25] <lool> asac: Which network type did you use?
[10:25] <lool> telnet should work
[10:25] <asac> lool: wget doesnt work
[10:25] <lool> that's bad
[10:26] <asac> next wanted to try a tap device
[10:26] <asac> but hoped i didnt need that
[10:26] <ogra> asac, what are the permissions of the img file (i havent uploaded the permission fix yet)
[10:26] <asac> let me run again
[10:26] <lool> asac: You don't
[10:26] <asac> ogra: permissions flag?
[10:26] <asac> what should be there?
[10:26] <asac> ogra: oh thats about rootfs not working?
[10:26] <lool> asac: ownership of the file needs to be the same as the user you're running the vm with
[10:26] <ogra> well, chown the img file
[10:26] <lool> and u+rw obviously
[10:26] <asac> right
[10:27] <asac> let me check
[10:27] <asac> but i could boot it now
[10:27] <ogra> the recent version saves the img as 666
[10:27] <asac> ls -l ubuntu-arm.img
[10:27] <asac> -rw-r--r-- 1 asac asac 2048000000 2010-03-18 11:22 ubuntu-arm.img
[10:27] <ogra> that should work for the asac user at least
[10:27] <asac> ogra: it boots
[10:28] <asac> i doubt that permission has to do something with network
[10:28] <ogra> so what exactly doesnt work
[10:28] <asac> wget
[10:28] <asac> after running dhclient
[10:28] <asac> and getting ip ;)
[10:28] <ogra> sudo dhclient eth0 ;)
[10:28] <asac> apt-get update -> errors
[10:28] <asac> ogra: well. read two lines above
[10:28] <ogra> weird, works here
[10:28] <asac> let me check host iptables
[10:29] <lool> ogra: 666 uh
[10:29] <asac> all open
[10:29] <asac> 644
[10:29] <lool> ogra: I seriously hope it's not 666, that'd be a major security issue
[10:29] <asac> yeah. 666 seems overly open ;)
[10:29] <ogra> sigh
[10:29] <ogra> 644 *doesnt boot*
[10:29] <lool> 666 it is   :-(
[10:30] <ogra> and i have no way to make sure to know which user will use it in the end
[10:30] <lool> Of course you do
[10:30] <ogra> since you removed all references to run qemu with sudo
[10:30] <ogra> lool, how, there are many people that use rootstock with cron
[10:30] <asac> now network works ;)
[10:30] <ogra> for daily local builds
[10:30] <lool> ogra: I've been running qemu all this time without sudo; kees setup the same thing yesterday, and didn't use sudo either or had any permissions issues
[10:30]  * asac likes things going away ;)
[10:31] <ogra> lool, with a 644 img owned by root.root and no initramfs ?
[10:31] <asac> ogra: why not chown to the user that called rootstock?
[10:31] <asac> oh
[10:31] <ogra> that would be cron for people doing daily builds
[10:31] <asac> well, maybe rootstock should call sudo on its own to figure the real owner
[10:32] <lool> ogra: Why would you want to own it by root?
[10:32] <ogra> lool, because it was loop mounterd and created as root it gets the systems default permissions
[10:32] <ogra> wich is 644 for the creating user
[10:32] <lool> ogra: I personally create the image as myself, and sudo loop-mnt it
[10:32] <asac> there is SUDO_USER ... so yeah. not sure why its a problem
[10:32] <asac> you could add an option to command line for cron folks
[10:32] <lool> Well either use SUDO_USER or actually only call sudo when you need to
[10:33] <asac> so they can say: --image-user=USER
[10:33] <lool> that's what I typically do in my scripts; they work as root or non-root, and call sudo when needed
[10:33] <lool> (We actually already had this discussion)
[10:33]  * ogra goes for asac's suggestion
[10:33] <lool> asac: Let's have a cp --user option too!  :-)
[10:34] <ogra> though i would prefer a more general fix ...
[10:34] <lool> Anyway, I filed a bug on the usage of 666; please never do that
[10:34] <ogra> its only in bzr yet, not in the archive
[10:34] <lool> I filed a bug upstream
[10:34] <ogra> fine, still, its a dev tree
[10:42] <asac> it all depends on the common use case
[10:42] <asac> i think using SUDO_USER makes sense
[10:42] <asac> --image-user might make sense, but you can also write a wrapper script in cron that does that i would think
[10:43] <asac> hmm
[10:43] <asac> printf ... how do i just flush stdout?
[10:44]  * asac tries
[10:44] <asac> ok that worked ;)(
[10:44] <asac> fflush stdout
[10:44] <lool> Oh I thought you were asking in shell and was puzzled
[10:45] <asac> heh
[10:45] <asac> no
[10:48] <ogra> hmm
[10:48]  * ogra ponders how to package x-loader
[10:49] <ogra> it sadly needs a fully configured uboot tree since the headers it relies on are generated by uboot configuration :/
[10:50] <asac> punch it into uboot? ;)
[10:50] <asac> or make uboot produce a -dev
[10:50] <ogra> then i would need to merge the upstream tarballs
[10:51] <ogra> -dev seems overly complicated ... especially in the light that we will need a -dev for each uboot flavour in the future then
[10:52] <asac> right
[10:52] <ogra> effectively i would like to have one uboot package based on upstream with lucid+1 (i.e. merge imx, omap and whatever else can use plain upstream or plain upstream with patches)
[10:52] <asac> if its soo tightly coupled upstream then it belongs together for now
[10:52] <lool> ogra: Really?
[10:52] <lool> I don't remember building xloader against uboot
[10:52] <ogra> so i dont want to bind to closely to the architecture for the omap package now, thats supposed to be the base for the merge
[10:53] <ogra> lool, well, i tried for zoom and beagle, both look in the boot tree for headers
[10:53] <lool> ogra: Which tree are you using?
[10:53] <lool> I just git clone gitorious:x-load-omap3/mainline.git and then:
[10:53] <lool> make CROSS_COMPILE=arm-none-eabi- distclean
[10:53] <lool> make CROSS_COMPILE=arm-none-eabi- omap3530beagle_config
[10:53] <lool> make CROSS_COMPILE=arm-none-eabi-
[10:53] <lool> and that's all
[10:54] <lool> I couldn't get the signed stuff to work
[10:55] <lool> well not the gpsign one but signGP.c worked
[10:55] <ogra> hmm, i pulled from the zoom tree, but that should essentially be the same (just with 3630 patches added)
[10:56] <ogra> the zoom tree expected to find ../u-boot/....*.h for building the ift image
[10:57] <ogra> (which you need for SD)
[10:57] <lool> http://code.google.com/p/beagleboard/wiki/BeagleSoftCompile doesn't mention building uboot first either
[10:57] <lool> ogra: What are you trying to build, the MMC version?  MLO?
[10:57] <ogra> both
[10:57] <lool> Err that's the same thing
[10:57] <ogra> i want a binary with a NAND and a MLO version
[10:57] <ogra> MOL has a dos header
[10:57] <ogra> *MLO
[10:58] <lool> MLO is the file which you write on your vfat
[10:58] <ogra> right
[10:58] <ogra> x-load.bin.ift is MLO
[10:58] <ogra> x-load.bin is for NAND
[10:58] <ogra> i need both
[10:59] <ogra> and for creating the ift version the build uses the uboot header files for some reason
[10:59] <lool> I'm not sure what the ift version is; I don't think I used that
[10:59] <ogra> at least in the zoom tree, i'll try the mainliune one
[10:59] <ogra> you cp .ift to MLO and cp it to your vfat to boot
[10:59] <lool> Oh that's just the signed one
[11:00] <lool> I know what you're trying to do now
[11:00] <ogra> its essentially a dos command.com after the signing
[11:00] <lool> You're trying to sign it with gpsign
[11:00] <ogra> right
[11:00] <lool> Which needs u-boot's headers
[11:00] <ogra> right :)
[11:00] <lool> Try signGP instead
[11:00] <lool> it doens't need anything
[11:00] <lool> and signGP didn't work for me anyway
[11:00] <lool> http://beagleboard.googlecode.com/files/signGP.c
[11:00] <ogra> well gpsign did
[11:01] <asac> ogra: when you hang in qemu is qemu completely dead?
[11:01] <asac> or can you ssh into it?
[11:01] <lool> err gpsign didn't work for me rather, typo
[11:01] <ogra> asac, i never tried to ssh, i use the graphical qemu version and switch to tty2
[11:01] <asac> ogra: so you can still log in?
[11:01] <ogra> yes
[11:01] <ogra> thats how i can see top ps etc
[11:02] <asac> send a signal to generate a core dump then please
[11:02] <ogra> to see the defunct dpkg --unpack passing by
[11:02] <ogra> what do you gain from a coredump without dbgsym ?
[11:02] <asac> ogra: you generate a core dump
[11:02] <asac> then install dbgsym to analyze
[11:02] <lool> you can load a core dump with dbgsyms from another system
[11:02] <ogra> right, but there are no symbols
[11:03] <ogra> oh
[11:03] <asac> first generate core dump
[11:03] <lool> it doesn't matter, it's just a memory image
[11:03] <asac> then install symbols and use gdb
[11:03] <asac> right
[11:03] <ogra> i'll try that later ... atm i want to get x-loader and uboot ready
[11:03] <asac> sure
[11:03] <asac> how do i start graphical qemu?
[11:04] <ogra> use the command from rootfsfromscratch
[11:04] <ogra> it fires up the SDL version by default
[11:04] <asac> i am using qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel ./vmlinuz -hda arm-rootfs.img -m 256 -append "root=/dev/sda mem=256M devtmpfs.mount=0 rw"
[11:05] <ogra> with alt-2 you get insto command mode and use send-key ctrl-alt-f2
[11:05] <asac> how do i switch to tty2 ?
[11:05] <asac> ah
[11:05] <asac> ok
[11:05] <ogra> to get back just send-key ctrl-alt-f1
[11:05] <asac> alt-2 == alt gr?
[11:05] <ogra> its annoying ... but the only way
[11:05] <ogra> alt and 2
[11:05] <ogra> alt-1 gets you back to the VM
[11:07] <asac> ogra its alt+f2 here :)
[11:07] <ogra> weird, alt f2 gets me the gnome exec dialog here
[11:08] <asac> you first have to click in the window ... so it grabs the input
[11:08] <asac> then alt+f2345 etc works as usual
[11:08] <asac> cool :)
[11:08] <ogra> heh, i always did it through the command console
[11:08] <ogra> because i'm annoyed if qemu grabs my mouse
[11:09]  * asac runs bzip2 to preserve state before installing netbook
[11:10] <asac> lets see how big it gets
[11:10] <ogra> heh. yeah
[11:16] <ogra> ./signGP x-load.bin 0x40208800
[11:16] <ogra> make: *** [x-load.bin.ift] Error 36
[11:16] <ogra> bah
[11:16] <ogra> funnily it produces x-load.bin.ift
[11:17] <asac> 100M
[11:17] <asac> ;)
[11:17] <ogra> sweet
[11:17] <asac> me uploads
[11:25] <asac> JamieBennett: all fine wfor the localization of .desktop?
[11:25] <asac> e..g did you get the answers from pitti?
[11:25] <asac> (or persia)
[11:26] <JamieBennett> asac: working on it. Its a lot more involved that first thought after I talked with persia
[11:26] <JamieBennett> and I'm learning how to do it for the first time
[11:26] <asac> so dh7 isnt ready for that?
[11:26] <asac> what a crap thing ;)
[11:26] <JamieBennett> asac: no
[11:27] <JamieBennett> I considered switching to CDBS
[11:27] <asac> ok
[11:27] <ogra> dont you just have to set gettext domain ?
[11:27] <asac> dh7 really isnt ready? wow
[11:27] <JamieBennett> but I have something that should be ready tomorrow
[11:27] <ogra> i thought LP cares for the rest
[11:27] <asac> ogra: we have cdbs langpack.mk
[11:27] <asac> seems we have no equiv. for dh7
[11:27] <JamieBennett> ogra: it was a simple wrapper script
[11:28] <lool> langpack.mk is mostly useful to desktop packages which used cdbs so far; no pressure to port it to dh basically
[11:28] <lool> but it should be done
[11:28] <JamieBennett> now it needs a build system (setup.py)
[11:28] <JamieBennett> and .po support
[11:28] <ogra> bah
[11:28] <JamieBennett> and gettext support
[11:28] <JamieBennett> e.t.c
[11:28] <lool> JamieBennett: which package is this?
[11:29] <JamieBennett> lool: webservice-office-zoho (my package)
[11:29] <lool> Truth is, the CDBS snippet should be a separate tool, perhaps a dh_langpack
[11:30] <JamieBennett> lool: I'm looking through doc, web pages, snippets of code trying to learn it too which doesn't help
[11:30] <lool> JamieBennett: You could copy what you need to some dh override
[11:31] <lool> JamieBennett: e.g. override dh_gencontrol
[11:31] <JamieBennett> lool: but would that be 'the proper way' ;)
[11:31] <lool> JamieBennett: Best way would be to add support to dh to do that automatically
[11:32] <lool> JamieBennett: But we have packages where we call intltool-update by hand because they are not CDBS based
[11:33] <lool> e.g. http://paste.ubuntu.com/397186/
[11:34] <lool> perhaps not very good examples actually
[11:39] <asac> current cdbs does stuff in binary-predeb
[11:42] <asac> ogra: http://people.canonical.com/~asac/tmp/ubuntu-arm-lucid-minimal.bz2 ;)
[11:42] <ogra> great
[11:43] <ogra> i have several of these around though ;)
[11:43] <asac> then why didnt you give them to me ;)
[11:43] <asac> thought you didnt have that online
[11:43] <ogra> i dont have them online
[11:44] <ogra> and we only discussed the compressing yesterday :)
[11:45] <asac> ah
[11:45] <asac> right. so now we have it ;)
[11:45] <ogra> yeah
[11:46] <asac> sigh ... i used 2G onlz
[11:46] <asac> thats not enough for netbook i think
[11:46] <lool> asac: You can grow it
[11:46] <asac> lool: command?
[11:46] <lool> asac: dd if=/dev/zero bs=1M count=200 >> lucid.img; e2fsck -f lucid.img; resize2fs -p lucid.img
[11:47] <lool> that's for a raw image
[11:47] <lool> (not sure whether you're using qcow or something)
[11:47] <asac> i use raw image with ext4
[11:47] <lool> no part table?
[11:47] <lool> then the above should work
[11:47] <asac> let me try
[11:47] <asac> not much to loose
[11:47] <ogra> rootstock doesnt create partitions
[11:47] <lool> Yeah, worst case you have 200MB of zeroes at the end
[11:47] <ogra> but creates ext3 by default
[11:48] <ogra> (or did i change that ?)
[11:48] <asac> ogra: i didnt use the img from rootstock, but made my own and untarred ;)
[11:49] <ogra> ah, but you used rootstock to create the tarball ?
[11:49] <asac> yes
[11:49] <asac> ok booting with new size
[11:49] <ogra> (i just wnt to be sure we're not to far away from the rootstock creation here when we try to debug)
[11:49] <ogra> thought its still weird that lool never saw that issue
[11:50] <asac> ok it worked
[11:50] <asac> now have 3g
[11:50] <ogra> that should suffice
[11:50] <ogra> i think even 2 would for armel netbook
[11:50] <asac> wasnt enough
[11:50] <ogra> (we dont have oo.o in the task)
[11:51] <asac> it wanted to install 1.8G after ubuntu-minimal
[11:51] <asac> and i only had 1.6G left or something
[11:53] <ogra> hmm, the task never wants to install that much for me
[11:53] <asac> its 1835MB
[11:53] <asac> so less than 1.8G ... but not much
[11:53] <asac> ^ubuntu-netbook
[11:53]  * ogra wonders if there is a size difference between task and metapackage
[11:54] <ogra> doesnt the caret need to be at the end ?
[11:54] <lool> asac: Are you trying to reproduce the problem or just analyze the core file?
[11:54] <asac> lool: want to reproduce and produce core files for now
[11:54] <asac> yes.
[11:54] <asac> lool: i already reproduced it here at some point
[11:55] <asac> furhter above there was someone who saw this even for ubuntu-minimal
[11:55] <asac> i think the faster the system is the easier you get it (race)
[11:55] <asac> as we dont see it with dbgsym installed according to ogra
[11:55] <ogra> right
[11:55] <ogra> installing dbgsym just makes it pass
[11:55] <lool> That's odd
[11:55] <ogra> i have never seen it in -minimal though
[11:56] <ogra> and i havent tried -desktop since we do -netbook
[11:58] <ogra> rcn-ee, you see the hang in rootstock too, right ?
[11:59] <rcn-ee> ogra, ah maybe, it's still halting at "|: Extracting zlib1g..." for me.. ;) debian qemu.. http://rcn-ee.homeip.net:81/dl/daily/ubuntu-lucid.log  but it worked just fine yesterday on karmic...
[12:00] <ogra> yes, its a lucid issue
[12:00] <ogra> though that is something different i think
[12:00] <rcn-ee> yeah i was guessing that, i need to setup a karmic chroot on my server...
[12:00] <ogra> do you have a full log too ? (the one that rootstock spits out if you ctrl-c)
[12:01] <rcn-ee> so you guys have fun building xloader/uboot for omap?
[12:01] <ogra> the prob is when building lucid ... not with lucid on the host
[12:01] <ogra> rcn-ee, well, fun is something different :) but yes, i'm fddling with that
[12:01] <rcn-ee> sorry, nope, it's a cron job, no terminal, and it doesn't occur when run from the command line...
[12:02] <ogra> ah
[12:03] <amitk> rcn-ee: I've seen the hang at zlib1g on karmic too
[12:03] <amitk> oops, ogra ^^
[12:03] <ogra> well, this hang is clearly not the same one
[12:03] <asac> why?
[12:04] <rcn-ee> ogra, under what conditions is it hanging now?
[12:04] <asac> i thought we hang in unpack too
[12:04] <ogra> unpacking of zlib happens in debootstrap which is run in the qemu-arm-static chroot
[12:04] <ogra> while the task installation hangs in a VM
[12:05] <asac> hmm. but why wouldnt an io issue in qemu never show up in qemu? maybe its just less easy to trigger because its a fresh process for every command?
[12:05] <rcn-ee> and what's weird, i had the same issue when building google's x86 os where it would hang on the same file, only x86.. ;)
[12:05] <asac> err second qemu==qemu-static
[12:05] <ogra> well, i have never seen it hang in karmic builds at all ... thats very new
[12:06] <asac> ogra: they install lucid .... didnt you say the host qemu doesnt matter?
[12:06] <ogra> but i definately can reproduce the netbook task install hang reliably in lucid
[12:06] <ogra> asac, right
[12:06] <ogra> host doesnt matter
[12:07] <rcn-ee> yeah no luck on netbook here either.. ;)
[12:07] <asac> so that they see something like this in karmic qemu when trying lucid doesnt feel that off based on that
[12:07] <ogra> but target lrelease of the build does
[12:07] <asac> right. armv7+thumb2
[12:07] <asac> in lucid
[12:07] <ogra> xactly my suspicion
[12:07] <asac> lool: why are you sure that armv7+thumb2 is working perfect in qemu?
[12:08] <asac> or arent you sure?
[12:08] <ogra> asac, you mean kernel wise
[12:08] <ogra> ?
[12:08] <asac> no ... qemu in general for now
[12:08] <asac> as rcn-ee sees it in static
[12:08] <ogra> i dont think qemu matters here
[12:09] <ogra> asac, but building a karmic image (unless i misunderstood)
[12:09] <asac> ogra: the log is named lucid from above: http://rcn-ee.homeip.net:81/dl/daily/ubuntu-lucid.log
[12:09] <ogra> i could imagine that the verstile kernel we use doesnt properly support thumb2
[12:09] <ogra> asac, oh
[12:10] <ogra> " but it worked just fine yesterday on karmic..."
[12:10] <asac> its probably a karmic qemu trying to run armv7/thumb2 code
[12:10] <ogra> that confused me :)
[12:10] <asac> hmm
[12:10] <asac> rcn-ee: so what are you doing?
[12:10] <asac> host = karmic + target == lucid?
[12:10] <asac> or both karmic / lucid ?
[12:10] <rcn-ee> ah crap, my naming confused everyone... host debian squeeze, running latest rootstock building ubuntu-netbook for lucid target... ;)
[12:10] <asac> yeah
[12:10] <ogra> debian squeeze ?
[12:11] <asac> so target is lucid
[12:11] <ogra> aww
[12:11] <ogra> thats a totally differend qemu then i think
[12:11] <asac> didnt lool land some arv7 stuff here?
[12:11] <asac> and not in debian? or are we in sync?
[12:11] <rcn-ee> just checking on that, it's qemu 0.11.1...
[12:11] <ogra> well, lool usually does his qemu stuff upstream
[12:11] <ogra> but we pull from a different upstream afaik
[12:11] <ogra> because of kvm
[12:12] <rcn-ee> and the opteron server i have is too old for kvm...
[12:12] <ogra> 0.12.3-0ubuntu15
[12:12] <ogra> thats what we have in lucid atm
[12:12] <ogra> but pulled from qemu-kvm since karmic
[12:13] <ogra> rcn-ee, well, kvm doesnt gain you anything for armel emu ... but the point is that we use a different upstream
[12:13] <asac> rigt. thats wat busted ftas images and he lost everything ;)
[12:14] <ogra> the question is how much difference there is
[12:14] <ogra> especially for armel
[12:14] <rcn-ee> correct... i just use it to verify nightly builds.. it was working early in lucid's cycle, maybe stoped in the last two months.. otherwise i build on karmic exclusively at work.. ;)
[12:15] <ogra> yeah, i dont test on debian ... so i dont really know if it would work or not
[12:16] <asac> ok hangs in iputils-tracepath here
[12:16] <ogra> minimal should work if you build on ubuntu host for all releases we support
[12:16] <ogra> asac, right, same here
[12:16] <ogra> that pretty reproducable
[12:16] <ogra> not 100% though ... there is another package it sometimes hangs ...
[12:17] <ogra> iso-codes iirc
[12:17] <nosse1> hi, guys. Back in business!
[12:17] <ogra> but i have only seeing it hang on either of these two yet
[12:17] <lool> asac: Sorry, I dont understand your question?
[12:17] <lool> asac: There might be qemu bugs
[12:17] <asac> ok
[12:17] <rcn-ee> it's been a toss up between iputils-tracepath and iso-codes for me..
[12:18] <lool> I wonder whether a FS benchmark would show a similar issue
[12:18] <nosse1> Have you come any closer to investigating the qemu hang? Is there anything I can assist with?
[12:18] <asac> lool: i ran a read/write testcase here today for 1h
[12:18] <asac> e.g. just reading and writing all the time
[12:18] <asac> that didnt have issues
[12:18] <ogra> lool, but are you sure that just telling the versatile kernel that it is a v7 CPU also enables all features properly (thumb2 etc)
[12:18] <asac> lool: which fs benchmark would you suggest?
[12:19] <asac> ok so now ... which process should i core dumb ;)?
[12:19] <asac> probably all dpkg/apt ones
[12:19] <ogra> i mean i see them in cpuinfo  ... but is it sure they actually work by just telling the kernel it is v7 ?
[12:19] <asac> not sure if i get the core from all though at the same time
[12:19] <lool> ogra: Uh the whole userspace works
[12:19] <ogra> well, apt is the one that hangs
[12:20] <lool> ogra: All our programs are running in thumb 2 mode aren't they
[12:20] <ogra> lool, yes
[12:20] <ogra> so you think other SW would expose issues too ?
[12:20] <lool> asac: Dunno, some kernel fs benchmark to cause high IO
[12:20] <lool> ogra: other SW?
[12:20] <ogra> (if it was kernel side)
[12:20] <ogra> other apps
[12:21] <lool> ogra, asac: One thing you folks could try to workaround the issue are different disk emulation in qemu; e.g. cache=none, cache=writeback, etc.
[12:21] <rcn-ee> aren't some packages, still in arm mode?
[12:21] <ogra> rcn-ee, very very few
[12:21] <lool> ogra: Well it might be a dpkg / apt bug exposed by our testing conditions or a qemu bug which triggers under high IO circunstances, perhaps a race
[12:21] <lool> ogra: I can't tell
[12:21] <ogra> yeah
[12:22] <asac> its definitly racish
[12:22] <asac> ok i have a core ... not sure if it was the apt or dpkg core though
[12:22] <ogra> i'm close to say its a race ... apt hanging in read() and the issue going away with dbgsym installed point very much to it
[12:23] <ogra> also the I/O isnt blocked if you work from another tty
[12:23] <ogra> while the hang occurs
[12:23] <nosse1> Is there a way I can circumvent the qemu-lockup from rootstock, so that I can build my ubuntu-minimal image?
[12:24] <ogra> nosse1, juts ubuntu-minimal should actually work
[12:24] <asac> nosse1: is the hang in second stage?
[12:24] <asac> then try another disk emulation as lool suggested above
[12:24] <nosse1> asac: Yes. "Switching to Virtual Machine for second stage processing"
[12:24] <ogra> nosse1, do you have a full log ?
[12:24] <asac> nosse1: then try to do that
[12:25] <lool> Another way might be to have a while sync; do sleep 1; done loop on another vt while doing the install
[12:25] <nosse1> ogra: Where can I find the log? Is it the rootstock-xxx.log file?
[12:25]  * lool lunch &
[12:25] <ogra> nosse1, right, rootstock should have told you it created the file when you stopped it (or it successfully finised)
[12:26] <ogra> can you put it somewhere so i can take a look where exactly it hangs
[12:27] <nosse1> The log files doesnt actuall tell anyting.. It shows the output from a wget session. Then "I: Killed ..."
[12:27] <ogra> whats your host os ?
[12:27] <nosse1> Karmic amd64
[12:27] <ogra> hmm, amd64
[12:28] <ogra> do you use the rootstock package from the archive ?
[12:28] <nosse1> yes
[12:28] <ogra> and you try to build lucid ?
[12:28] <nosse1> yes
[12:28] <ogra> ah
[12:28] <ogra> thats fixed but not backported to karmic
[12:28] <nosse1> should I up my host to lucid then?
[12:29] <ogra> http://bazaar.launchpad.net/~project-rootstock-developers/project-rootstock/trunk/revision/31
[12:29] <ogra> the rootstock scrip needs this fix
[12:30] <ogra> (currently karmic can only build karmic)
[12:30] <ogra> (without this fix)
[12:31]  * ogra tries to find some food
[12:39] <nosse1> The ultimate goal of this is to throw Ubuntu into an embedded product which will go into mass production. What is the state of Ubuntu Lucid for ARM?
[12:39] <nosse1> The product is at least 12-14 mnths away from release
[12:39] <asac> nosse1: lucid for arm is quite good. we release beta today
[12:39] <asac> rootstock is busted though ;)
[12:40] <asac> there are a few ftbfs and thumb2 porting issues outstanding
[12:40] <nosse1> Since we're using a Zoom TI AM3517 evaluation kit as a base, is there something I can do to contribute for support for that exact kit?
[12:41] <nosse1> Pardon my silly questions, I'm quite new to the development flows of Ubuntu :o
[12:45] <asac> nosse1: yes, testing like you do now is good. also checking if there is software for that that isnt in the archive would help (besides the kernel/bootloader)
[12:45] <nosse1> I see from the topic that "no, we do not cross compile"? What do you mean? That all packages are built natively on some target/emu?
[12:45] <asac> nosse1: we build natively on real machines
[12:46] <asac> nosse1: if there are particular software you need to cross compile let me know which software that is
[12:46] <asac> currently collecting the main use cases we should support in some way
[12:47] <asac> nosse1: here you can see our build farm: https://edge.launchpad.net/builders
[12:47] <nosse1> we will have Qt (>=4.6) running, but if it need cross compile I'm not sure yet
[12:47] <asac> nosse1: is that newer than in ubuntu?
[12:47] <nosse1> than karmic, yes. I havent checked lucid yet
[12:47] <asac> we have Version: 4:4.6.2-0ubuntu
[12:47] <asac> in lucid
[12:48] <asac> at least thats the version for libqt4-dev
[12:48] <asac> so thats already precompiled in lucid for you
[12:48] <nosse1> Thats latest release from Qt
[12:48] <asac> if you have fixes for that that you need to get in and that are general issues we can try to get that patched
[12:48] <rcn-ee> * heads off to work, needs to stop playing with the xm board and send amit some usb/musb patches for omap..
[12:49] <ynezz> how's xm? :)
[12:49] <rcn-ee> i like it. ;)
[12:49] <nosse1> I'm a little uncertain how the rendering system should be done in Qt and/or X11. Because the SDK to access the HW GFX accelerators are not open source
[12:50] <asac> nosse1: so to get unbut-minimal all you need to do is to create it from lucid (not debian)
[12:50] <asac> that definitly works for everyone here
[12:57] <nosse1> Yes! The patch to rootstock worked!
[13:01] <nosse1> How can I install or sign up for a builder in the build farm?
[13:02] <nosse1> I mean, the process from making a source package up until it ends up in a apt tree is really unknown to me
[13:02] <nosse1> Because we will have to make our own apt tree for the closed applications and such
[16:18] <ogra> ogra@osiris:~/Devel/branches/omap$ sudo build-arm-chroot lucid /mnt http://192.168.2.87:9999/ubuntu-ports
[16:18] <ogra> W: Target architecture is the same as host architecture; disabling QEMU support
[16:18] <ogra> lool, that seems broken
[16:19] <ogra> either drop build-arm-chroot or make it set --arch armel
[16:20] <amitk> ogra: omap image? :-p
[16:21]  * amitk hides
[16:21]  * ogra hits amitk with a rootstock
[16:21] <ogra> :)
[16:22] <amitk> :)
[16:22] <amitk> the kernel should the archive tomorrow
[16:22] <amitk> *hit the archive
[16:22] <ogra> great, i'll make sure x-loader and uboot are uploaded before end of day tomorrow
[16:23] <ogra> and will work on cdimage scripts on the weekend
[16:25] <armin76> you guys doing omap support now?
[16:30] <DanaG> OOooh.
[16:31] <DanaG> heh, every time I try to compile a "newer" u-boot (u-boot-omap) for my beagleboard, I find it mistakenly detects it as Board Revision Ax/Bx (instead of C4, as it should be).
[16:31] <DanaG> hmm, what benefit do a newer u-boot and/or x-loader give?
[16:33] <DanaG> http://pastebin.com/BFjBG4Ms --  vlc segfaults.
[16:33] <DanaG> er, sorry for the long command line. =þ   Oh, and mplayer is UNAVAILABLE.
[16:34] <DanaG> heh, I left in my sd card with Angstrom (ew) on it, and grub on my host "Found unknown Linux distribution on /dev/mmcblk0p2
[16:37] <ogra> DanaG, mplayer is availabel in multiverse
[16:38] <DanaG> hmm, I'll check sources.list.
[16:38] <ogra> for vlc, please file a bug
[16:38] <ogra> (and hope that someone from the community puts some work into it)
[16:39] <DanaG> How do I trigger apport via CLI?
[16:39] <ogra> ubuntu-bug vlc
[16:39] <ogra> should work
[16:39] <DanaG> Will it get the gdb output?
[16:40] <ogra> if there was a crash file file created it will just attach it
[16:40] <DanaG> Cool.
[16:40] <ogra> check /var/crash/
[16:41] <DanaG> nope, no vlc .crash file.
[16:43] <DanaG> also, when trying to run amttool on the beagle:
[16:43] <DanaG> Can't locate SOAP/Lite.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/bin/amttool line 4.
[16:43] <DanaG> BEGIN failed--compilation aborted at /usr/bin/amttool line 4.
[16:44] <ogra> looks like a missing dependency ...
[16:44] <ogra> a bug as well
[16:45] <ogra> the community support for apps in universe under armel isnt that great yet
[16:45] <ogra> (any help appreciated :) )
[16:46] <DanaG> hah, nvidia-kernel-common exists on ARM restricted.
[16:54] <DanaG> heh, and so do things like virtualbox-guest-additions.
[17:04] <KingMuty> yo
[17:09] <DanaG> weird... ssh into beagleboard and run mplayer... it outputs LOCALLY to pulseaudio on the ssh client.
[17:10] <DanaG> ah, had to un-export DISPLAY=
[17:12] <lool> ogra: build-arm-chroot does set arch == armel
[17:13] <ogra> lool, didnt for me
[17:13] <lool> ogra: But you're running this on arm, right?
[17:13] <ogra> no
[17:13] <ogra> i just tried to quickly build an arm chroot
[17:13]  * DanaG wishes he had a spare DVI display.
[17:13] <lool> ogra: Ah I know what happened
[17:13] <DanaG> Right now, my beagleboard is entirely headless.
[17:13] <ogra> lool, it also doesnt throw the deprecation warning
[17:15] <lool> ogra: uploaded
[17:15] <lool> ogra: http://paste.ubuntu.com/397356/
[17:16] <ogra> lool, hmm
[17:16] <ogra> lool, i didnt run build-arm-chroot with a path
[17:16] <lool> ogra: sudo added one
[17:17] <ogra> oh
[17:17] <ogra> indeed :)
[17:17] <KingMuty> yo
[17:17] <ogra> ghurt
[17:18] <KingMuty> juje
[17:19] <KingMuty> http://blokker1999.info/andromnia/README.txt
[17:19] <KingMuty> dis ewe do?
[17:21] <KingMuty> ewe no talk?
[17:25] <ogra> KingMuty, try #andromnia
[17:25] <KingMuty> ok thx
[17:29] <KingMuty> dey iz dead! :'(
[17:47] <DanaG> interesting... so, if I wanted to have pulseaudio run as my local user... how would I make it auto-start on a headless thingy?
[17:48] <DanaG> now, here's something funny to do:
[17:49] <DanaG> screen /dev/ttyUSB0 115200 on host, to beagleboard serial port.
[17:49] <DanaG> now run byobu within that.
[17:49] <DanaG> And then within byobu... use amtterm to go back to the host.
[17:49] <DanaG> ... and then run another byobu there.
[17:50] <DanaG> or even better... make the first "screen" a byobu, too.