=== Laibsch1 is now known as Laibsch === Laibsch1 is now known as Laibsch === Laibsch1 is now known as Laibsch [06:57] http://pastebin.com/BFjBG4Ms [06:57] vlc segfaults. [06:59] er, sorry for the long command line. =þ [07:00] interesting... mplayer is UNAVAILABLE [07:07] alsaplayer works, though. once I add myself to "audio" group. [09:10] hi folks [09:13] * ogra gets more coffee [09:13] morning asac [09:14] grmbl ... /me curses having to port uboot patches to redboot ... [09:26] heh, fun ... the change i should revert in redboot-imx doesnt seem to exist in our version at all [09:30] hi ogra [09:34] 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] I forgot to say that I have a TI AM3517 ZOOM development kit [09:38] 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] nosse1: welcome [09:40] 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] we've just started supporting OMAP3 kernels in the next release of Ubuntu [09:41] nosse1: Lucid is guilty as charged [09:43] I started rootstock, and when it spawns qemu, it locks up my CPU at 100%. Is this familiar? [09:44] ogra <--- blame him [09:45] I have no kind of feedback, so I don [09:45] ...don't know if it has locked up or doing something sensible... [09:46] (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] no, i use rootstock on 64-bit successfully [09:48] 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] nosse1: yes, the CPU issue is known [09:50] e.g. for qemu [09:50] investigation ongoing [09:50] seems its triggered by apt [09:50] or rather dpkg somehow [09:50] asac: But is it dead or processing something? [09:51] asac: Can I cat into its output somewhere? [09:52] nosse1: its dead. we think its qemu being broken [09:52] ogra: why is the bug not filed against rootstock nor qemu-kvm? [09:53] asac: Thanks [09:54] its bug 532733 [09:54] 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] nosse1: ^ [09:57] I running Karmic on my host. Would it (not for this specific thing, but generally) be better to run lucid? [09:57] host system seems to make no difference afaict [09:58] its lucid vm that causes this [09:59] 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] interesting [09:59] but you are installing lucid? [09:59] yes [09:59] e.g. in the vm? [09:59] i suspect this to be a racy thing [09:59] the biggere the task is the more likely you hit it [09:59] for us ubuntu-minimal works usually, but netbook triggeres this [10:00] but i dontsee why ubuntu-minimal wouldnt cause this for some [10:00] I can probably strace it, but I'll have to leave for a meeting first... [10:00] what are your host specs? [10:00] e.g. what system is this running on? [10:00] wouldn't it depend on the system specs too? [10:00] aah, exactly [10:00] Ubuntu Karmic amd64 [10:00] nosse1: your HW spec [10:00] well. cpu mem etc. [10:01] maybe also disk speed etc. [10:01] Where can I find disk speed? [10:02] hdparams? [10:02] hdparm ;) [10:02] Intel C2Duo T9900, 3.06GHz, 8Gb RAM, Disk: 101MB/sec [10:02] well, but you could say: 5400 / 7200 / SSD etc. [10:03] 7200 for my case [10:03] I'm sorry, but I have to leave. I'll be back. Thanks guys [10:03] 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] so makes some sense that you see it earlier [10:13] ogra: your instructions dont work [10:13] e.g. the saved qemu image isnt good [10:13] getting unable to mount rootfs [10:13] sure root=/dev/sda? [10:13] I: Mounting temporary Image [10:13] I: ARM rootfs created as /tmp/qemu/armel-rootfs-201003181055.tgz [10:13] I: Qemu image saved as /tmp/qemu/qemu-armel-201003181055.img [10:14] i use that img [10:14] ogra: ^^ [10:18] ok manually creating .img works it seems [10:18] why is the kept img broken? [10:24] hmm [10:24] "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] that doesnt work for me [10:24] ogra: ^^ [10:24] i can get an ip with dhclient [10:24] but not ping out [10:24] or wget [10:25] asac: ping is special though [10:25] asac: Which network type did you use? [10:25] telnet should work [10:25] lool: wget doesnt work [10:25] that's bad [10:26] next wanted to try a tap device [10:26] but hoped i didnt need that [10:26] asac, what are the permissions of the img file (i havent uploaded the permission fix yet) [10:26] let me run again [10:26] asac: You don't [10:26] ogra: permissions flag? [10:26] what should be there? [10:26] ogra: oh thats about rootfs not working? [10:26] asac: ownership of the file needs to be the same as the user you're running the vm with [10:26] well, chown the img file [10:26] and u+rw obviously [10:26] right [10:27] let me check [10:27] but i could boot it now [10:27] the recent version saves the img as 666 [10:27] ls -l ubuntu-arm.img [10:27] -rw-r--r-- 1 asac asac 2048000000 2010-03-18 11:22 ubuntu-arm.img [10:27] that should work for the asac user at least [10:27] ogra: it boots [10:28] i doubt that permission has to do something with network [10:28] so what exactly doesnt work [10:28] wget [10:28] after running dhclient [10:28] and getting ip ;) [10:28] sudo dhclient eth0 ;) [10:28] apt-get update -> errors [10:28] ogra: well. read two lines above [10:28] weird, works here [10:28] let me check host iptables [10:29] ogra: 666 uh [10:29] all open [10:29] 644 [10:29] ogra: I seriously hope it's not 666, that'd be a major security issue [10:29] yeah. 666 seems overly open ;) [10:29] sigh [10:29] 644 *doesnt boot* [10:29] 666 it is :-( [10:30] and i have no way to make sure to know which user will use it in the end [10:30] Of course you do [10:30] since you removed all references to run qemu with sudo [10:30] lool, how, there are many people that use rootstock with cron [10:30] now network works ;) [10:30] for daily local builds [10:30] 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] lool, with a 644 img owned by root.root and no initramfs ? [10:31] ogra: why not chown to the user that called rootstock? [10:31] oh [10:31] that would be cron for people doing daily builds [10:31] well, maybe rootstock should call sudo on its own to figure the real owner [10:32] ogra: Why would you want to own it by root? [10:32] lool, because it was loop mounterd and created as root it gets the systems default permissions [10:32] wich is 644 for the creating user [10:32] ogra: I personally create the image as myself, and sudo loop-mnt it [10:32] there is SUDO_USER ... so yeah. not sure why its a problem [10:32] you could add an option to command line for cron folks [10:32] Well either use SUDO_USER or actually only call sudo when you need to [10:33] so they can say: --image-user=USER [10:33] that's what I typically do in my scripts; they work as root or non-root, and call sudo when needed [10:33] (We actually already had this discussion) [10:33] * ogra goes for asac's suggestion [10:33] asac: Let's have a cp --user option too! :-) [10:34] though i would prefer a more general fix ... [10:34] Anyway, I filed a bug on the usage of 666; please never do that [10:34] its only in bzr yet, not in the archive [10:34] I filed a bug upstream [10:34] fine, still, its a dev tree [10:42] it all depends on the common use case [10:42] i think using SUDO_USER makes sense [10:42] --image-user might make sense, but you can also write a wrapper script in cron that does that i would think [10:43] hmm [10:43] printf ... how do i just flush stdout? [10:44] * asac tries [10:44] ok that worked ;)( [10:44] fflush stdout [10:44] Oh I thought you were asking in shell and was puzzled [10:45] heh [10:45] no [10:48] hmm [10:48] * ogra ponders how to package x-loader [10:49] it sadly needs a fully configured uboot tree since the headers it relies on are generated by uboot configuration :/ [10:50] punch it into uboot? ;) [10:50] or make uboot produce a -dev [10:50] then i would need to merge the upstream tarballs [10:51] -dev seems overly complicated ... especially in the light that we will need a -dev for each uboot flavour in the future then [10:52] right [10:52] 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] if its soo tightly coupled upstream then it belongs together for now [10:52] ogra: Really? [10:52] I don't remember building xloader against uboot [10:52] 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] lool, well, i tried for zoom and beagle, both look in the boot tree for headers [10:53] ogra: Which tree are you using? [10:53] I just git clone gitorious:x-load-omap3/mainline.git and then: [10:53] make CROSS_COMPILE=arm-none-eabi- distclean [10:53] make CROSS_COMPILE=arm-none-eabi- omap3530beagle_config [10:53] make CROSS_COMPILE=arm-none-eabi- [10:53] and that's all [10:54] I couldn't get the signed stuff to work [10:55] well not the gpsign one but signGP.c worked [10:55] hmm, i pulled from the zoom tree, but that should essentially be the same (just with 3630 patches added) [10:56] the zoom tree expected to find ../u-boot/....*.h for building the ift image [10:57] (which you need for SD) [10:57] http://code.google.com/p/beagleboard/wiki/BeagleSoftCompile doesn't mention building uboot first either [10:57] ogra: What are you trying to build, the MMC version? MLO? [10:57] both [10:57] Err that's the same thing [10:57] i want a binary with a NAND and a MLO version [10:57] MOL has a dos header [10:57] *MLO [10:58] MLO is the file which you write on your vfat [10:58] right [10:58] x-load.bin.ift is MLO [10:58] x-load.bin is for NAND [10:58] i need both [10:59] and for creating the ift version the build uses the uboot header files for some reason [10:59] I'm not sure what the ift version is; I don't think I used that [10:59] at least in the zoom tree, i'll try the mainliune one [10:59] you cp .ift to MLO and cp it to your vfat to boot [10:59] Oh that's just the signed one [11:00] I know what you're trying to do now [11:00] its essentially a dos command.com after the signing [11:00] You're trying to sign it with gpsign [11:00] right [11:00] Which needs u-boot's headers [11:00] right :) [11:00] Try signGP instead [11:00] it doens't need anything [11:00] and signGP didn't work for me anyway [11:00] http://beagleboard.googlecode.com/files/signGP.c [11:00] well gpsign did [11:01] ogra: when you hang in qemu is qemu completely dead? [11:01] or can you ssh into it? [11:01] err gpsign didn't work for me rather, typo [11:01] asac, i never tried to ssh, i use the graphical qemu version and switch to tty2 [11:01] ogra: so you can still log in? [11:01] yes [11:01] thats how i can see top ps etc [11:02] send a signal to generate a core dump then please [11:02] to see the defunct dpkg --unpack passing by [11:02] what do you gain from a coredump without dbgsym ? [11:02] ogra: you generate a core dump [11:02] then install dbgsym to analyze [11:02] you can load a core dump with dbgsyms from another system [11:02] right, but there are no symbols [11:03] oh [11:03] first generate core dump [11:03] it doesn't matter, it's just a memory image [11:03] then install symbols and use gdb [11:03] right [11:03] i'll try that later ... atm i want to get x-loader and uboot ready [11:03] sure [11:03] how do i start graphical qemu? [11:04] use the command from rootfsfromscratch [11:04] it fires up the SDL version by default [11:04] 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] with alt-2 you get insto command mode and use send-key ctrl-alt-f2 [11:05] how do i switch to tty2 ? [11:05] ah [11:05] ok [11:05] to get back just send-key ctrl-alt-f1 [11:05] alt-2 == alt gr? [11:05] its annoying ... but the only way [11:05] alt and 2 [11:05] alt-1 gets you back to the VM [11:07] ogra its alt+f2 here :) [11:07] weird, alt f2 gets me the gnome exec dialog here [11:08] you first have to click in the window ... so it grabs the input [11:08] then alt+f2345 etc works as usual [11:08] cool :) [11:08] heh, i always did it through the command console [11:08] because i'm annoyed if qemu grabs my mouse [11:09] * asac runs bzip2 to preserve state before installing netbook [11:10] lets see how big it gets [11:10] heh. yeah [11:16] ./signGP x-load.bin 0x40208800 [11:16] make: *** [x-load.bin.ift] Error 36 [11:16] bah [11:16] funnily it produces x-load.bin.ift [11:17] 100M [11:17] ;) [11:17] sweet [11:17] me uploads [11:25] JamieBennett: all fine wfor the localization of .desktop? [11:25] e..g did you get the answers from pitti? [11:25] (or persia) [11:26] asac: working on it. Its a lot more involved that first thought after I talked with persia [11:26] and I'm learning how to do it for the first time [11:26] so dh7 isnt ready for that? [11:26] what a crap thing ;) [11:26] asac: no [11:27] I considered switching to CDBS [11:27] ok [11:27] dont you just have to set gettext domain ? [11:27] dh7 really isnt ready? wow [11:27] but I have something that should be ready tomorrow [11:27] i thought LP cares for the rest [11:27] ogra: we have cdbs langpack.mk [11:27] seems we have no equiv. for dh7 [11:27] ogra: it was a simple wrapper script [11:28] langpack.mk is mostly useful to desktop packages which used cdbs so far; no pressure to port it to dh basically [11:28] but it should be done [11:28] now it needs a build system (setup.py) [11:28] and .po support [11:28] bah [11:28] and gettext support [11:28] e.t.c [11:28] JamieBennett: which package is this? [11:29] lool: webservice-office-zoho (my package) [11:29] Truth is, the CDBS snippet should be a separate tool, perhaps a dh_langpack [11:30] lool: I'm looking through doc, web pages, snippets of code trying to learn it too which doesn't help [11:30] JamieBennett: You could copy what you need to some dh override [11:31] JamieBennett: e.g. override dh_gencontrol [11:31] lool: but would that be 'the proper way' ;) [11:31] JamieBennett: Best way would be to add support to dh to do that automatically [11:32] JamieBennett: But we have packages where we call intltool-update by hand because they are not CDBS based [11:33] e.g. http://paste.ubuntu.com/397186/ [11:34] perhaps not very good examples actually [11:39] current cdbs does stuff in binary-predeb [11:42] ogra: http://people.canonical.com/~asac/tmp/ubuntu-arm-lucid-minimal.bz2 ;) [11:42] great [11:43] i have several of these around though ;) [11:43] then why didnt you give them to me ;) [11:43] thought you didnt have that online [11:43] i dont have them online [11:44] and we only discussed the compressing yesterday :) [11:45] ah [11:45] right. so now we have it ;) [11:45] yeah [11:46] sigh ... i used 2G onlz [11:46] thats not enough for netbook i think [11:46] asac: You can grow it [11:46] lool: command? [11:46] asac: dd if=/dev/zero bs=1M count=200 >> lucid.img; e2fsck -f lucid.img; resize2fs -p lucid.img [11:47] that's for a raw image [11:47] (not sure whether you're using qcow or something) [11:47] i use raw image with ext4 [11:47] no part table? [11:47] then the above should work [11:47] let me try [11:47] not much to loose [11:47] rootstock doesnt create partitions [11:47] Yeah, worst case you have 200MB of zeroes at the end [11:47] but creates ext3 by default [11:48] (or did i change that ?) [11:48] ogra: i didnt use the img from rootstock, but made my own and untarred ;) [11:49] ah, but you used rootstock to create the tarball ? [11:49] yes [11:49] ok booting with new size [11:49] (i just wnt to be sure we're not to far away from the rootstock creation here when we try to debug) [11:49] thought its still weird that lool never saw that issue [11:50] ok it worked [11:50] now have 3g [11:50] that should suffice [11:50] i think even 2 would for armel netbook [11:50] wasnt enough [11:50] (we dont have oo.o in the task) [11:51] it wanted to install 1.8G after ubuntu-minimal [11:51] and i only had 1.6G left or something [11:53] hmm, the task never wants to install that much for me [11:53] its 1835MB [11:53] so less than 1.8G ... but not much [11:53] ^ubuntu-netbook [11:53] * ogra wonders if there is a size difference between task and metapackage [11:54] doesnt the caret need to be at the end ? [11:54] asac: Are you trying to reproduce the problem or just analyze the core file? [11:54] lool: want to reproduce and produce core files for now [11:54] yes. [11:54] lool: i already reproduced it here at some point [11:55] furhter above there was someone who saw this even for ubuntu-minimal [11:55] i think the faster the system is the easier you get it (race) [11:55] as we dont see it with dbgsym installed according to ogra [11:55] right [11:55] installing dbgsym just makes it pass [11:55] That's odd [11:55] i have never seen it in -minimal though [11:56] and i havent tried -desktop since we do -netbook [11:58] rcn-ee, you see the hang in rootstock too, right ? [11:59] 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] yes, its a lucid issue [12:00] though that is something different i think [12:00] yeah i was guessing that, i need to setup a karmic chroot on my server... [12:00] do you have a full log too ? (the one that rootstock spits out if you ctrl-c) [12:01] so you guys have fun building xloader/uboot for omap? [12:01] the prob is when building lucid ... not with lucid on the host [12:01] rcn-ee, well, fun is something different :) but yes, i'm fddling with that [12:01] sorry, nope, it's a cron job, no terminal, and it doesn't occur when run from the command line... [12:02] ah [12:03] rcn-ee: I've seen the hang at zlib1g on karmic too [12:03] oops, ogra ^^ [12:03] well, this hang is clearly not the same one [12:03] why? [12:04] ogra, under what conditions is it hanging now? [12:04] i thought we hang in unpack too [12:04] unpacking of zlib happens in debootstrap which is run in the qemu-arm-static chroot [12:04] while the task installation hangs in a VM [12:05] 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] 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] err second qemu==qemu-static [12:05] well, i have never seen it hang in karmic builds at all ... thats very new [12:06] ogra: they install lucid .... didnt you say the host qemu doesnt matter? [12:06] but i definately can reproduce the netbook task install hang reliably in lucid [12:06] asac, right [12:06] host doesnt matter [12:07] yeah no luck on netbook here either.. ;) [12:07] so that they see something like this in karmic qemu when trying lucid doesnt feel that off based on that [12:07] but target lrelease of the build does [12:07] right. armv7+thumb2 [12:07] in lucid [12:07] xactly my suspicion [12:07] lool: why are you sure that armv7+thumb2 is working perfect in qemu? [12:08] or arent you sure? [12:08] asac, you mean kernel wise [12:08] ? [12:08] no ... qemu in general for now [12:08] as rcn-ee sees it in static [12:08]