**** BEGIN LOGGING AT Wed Mar 16 02:59:57 2011 Mar 16 09:00:21 ericm|ubuntu: ping Mar 16 09:39:26 ericm|ubuntu: ping Mar 16 12:16:54 ericm|ubuntu: still no sound after fiddling with alsamixer&c, can you confirm me that you've never heard any sound out of this board? (it's an A0 BTW) did you use another board previously for audio related stuff? Mar 16 12:22:04 ppisati, never tried on that board Mar 16 12:22:11 ppisati, X0 was OK Mar 16 12:22:11 ericm|ubuntu: ok, thanks Mar 16 12:22:30 ericm|ubuntu: i'll ask grue and ncomm when they wake up Mar 16 12:22:37 ericm|ubuntu: do you know if they have A0? Mar 16 12:22:37 ppisati, 'k Mar 16 12:22:53 ppisati, they should Mar 16 12:22:58 ericm|ubuntu: k Mar 16 12:25:27 GrueMaster: ping Mar 16 13:11:11 hi guys. i've got my cross-compiled kernel running with a rootstock-filesystem. now i'd like to cross-comile some applications, but im struggling with dependencies since i get use apt-get build-dep... is somebody out there who could help me out a lil? =) Mar 16 13:11:35 **can't use apt-get build-dep.. :-/ Mar 16 13:12:05 do native builds or use xdeb, but it doesnt work with all packages afaik Mar 16 13:12:54 ogra_: so you mean natively build every package im depending on? Mar 16 13:13:09 no, native vs cross Mar 16 13:13:17 oohhh Mar 16 13:13:37 then I'd have to install the full build-essentials on the device? Mar 16 13:13:42 you can either do that on the real HW or in a chroot on the machine you used rootstock on Mar 16 13:13:47 hhmmm i was hoping i could avoid that Mar 16 13:14:31 ? chroot between platforms? i thought thats impossible Mar 16 13:14:31 create a dir (call it chroot or so) and untar the rootstock tarball to it Mar 16 13:14:43 yeah i got that dir Mar 16 13:15:03 sudo cp /usr/bin/qemu-arm-static Mar 16 13:15:12 i did a chroot do add / remove users, but executing arm binaries on a x64 machin?! *confused* Mar 16 13:15:13 then you can just chroot Mar 16 13:15:42 uh that sounds good... let me try it, brb. =) Mar 16 13:16:19 qemu-arm-static then wraps arm syscalls around every binary and translates them to x86 while you work inside the chroot Mar 16 13:17:11 its slower than a real cross build, but prevents you from having to build on your HW Mar 16 13:17:35 and you might hit syscalls that arent implemented, for 90% of the stuff it works fine though Mar 16 13:18:14 :-O Mar 16 13:18:40 duuuuuude... im just apt-get updating my arm system on my x64 laptop... *lol* Mar 16 13:18:42 awesome Mar 16 13:18:46 now let me try install gcc Mar 16 13:19:35 hmmm Unsupported ioctl: cmd=0xffffffffc020660b Mar 16 13:19:46 janimo, whats the magic kernel cmdline i have to use for my panda to not have it constantly change its IP ? Mar 16 13:19:51 its still running though Mar 16 13:19:59 lil_pete, just ignore that Mar 16 13:20:12 there might also be unsupported syscall messages too Mar 16 13:22:24 lil_pete: Use some newer qemu; the ~linaro-maintainers/tools PPA has a quite up-to-date one, I'd be surprized if you still got ioctl warnings with it Mar 16 13:23:06 * ogra_ must admit he hasnt tried the linaro qemu yet but i'm sure lool is right here Mar 16 13:23:21 lool: sorry, you lost me at "~linaro-maintainers/tools PPA"... ? Mar 16 13:23:36 <-- pretty noobish student :) Mar 16 13:23:51 launchpad.net/~linaro-maintainers/tools Mar 16 13:24:01 aaahhhhh Mar 16 13:24:15 * lil_pete will be installing. :) Mar 16 13:24:25 lil_pete: add-apt-repository ppa:linaro-maintainers/tools Mar 16 13:24:49 Install qemu-user-static from this PPA, and you should get freshest qemu-linaro which fixes a bunch of missing support for some ioctls or syscalls Mar 16 13:24:51 https://launchpad.net/~linaro-maintainers/+archive/tools Mar 16 13:24:52 oh yeah that sounds good... Mar 16 13:37:51 hhmmm apt cant resolve the ppa:launchpad hostname? did i miss something? Mar 16 13:38:47 ogra_, I don;t think there is a kernel cmd option. I just set static IP in /e/n/i Mar 16 13:39:05 well, iirc there was a way to give it a fixed MAC Mar 16 13:39:29 ogra_, no idea about that Mar 16 13:39:33 currently my mac changes all the time which makes the board change its IP (i would like to go on using dhcp here) Mar 16 13:40:35 ogra_, rsalveti may know. Mar 16 13:41:02 hmm, i'll resort to /e/n/i somehow for now Mar 16 13:41:36 ogra_: there was a cmdline argument that you could specify the mac address Mar 16 13:41:46 and you could also put it at network interfaces Mar 16 13:41:57 ftbfs status list seems to be updated less often Mar 16 13:42:19 rsalveti, yeah, thats what i remember, i was to lazy to dig in the bugs :) Mar 16 13:42:29 janimo, should be twice a day Mar 16 13:42:55 probably it was dropped to once a day because it took to long to get all the data Mar 16 13:43:19 persia would know if he had some way to think about such stuff atm i guess Mar 16 13:46:06 ogra_: bug 673504 Mar 16 13:46:07 Launchpad bug 673504 in linux-ti-omap4 "Pandaboard chooses a new IP address on each boot" [High,Fix released] https://launchpad.net/bugs/673504 Mar 16 13:46:37 hmm, it actually doesnt do that on each boot but while i'm connected via ssh Mar 16 13:47:44 and checking even more, i just see it doesnt actually change the MAC at all Mar 16 13:48:06 i wonder if there is something wrong with PM that powers off the NIC regulary Mar 16 13:48:24 dmesg is quiet though Mar 16 13:52:40 NCommander: ping Mar 16 14:17:22 ppisati: pong. On the dove boards, we used X0 for Lucid and A0 for Maverick. Both have different audio codec chips. Mar 16 14:17:37 No audio on Maverick. Mar 16 14:24:05 GrueMaster: that means we need a new update BSP from Marvell to get the audio for A0? Mar 16 14:25:02 Yes, but I wouldn't worry about it unless oem has a project that needs it. We were only doing maverick to enable OEM. Mar 16 14:26:00 nobody uses the dove maveric kernel Mar 16 14:26:19 actually i can't even find a maverick image for dove Mar 16 14:26:44 there was one, completely untested iirc but i know we built it Mar 16 14:30:27 ogra: i think i'll my own, just for testing Mar 16 14:30:39 http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/release/ Mar 16 14:33:52 ogra: cool, thanks! :) Mar 16 14:41:41 ogra: xcuse my being so rude, i was so xcited about that chroot-ability. just wanted to say thanks man, you made my day. :) Mar 16 14:42:09 heh, you werent rude :) Mar 16 14:42:22 and lool helped too :) Mar 16 14:42:38 well i just left, if this were a real room that would have been more than rude. Mar 16 14:42:51 lool: thank you too, of course. dont wanna leave nobody out... :D Mar 16 15:31:47 looking at the kde ftbfs packages, it looks like they all fail due to differences in GL header typedefs. Mar 16 15:39:33 could be that it's compiling with gl support, but using the libqt4-opengl with gles Mar 16 15:39:50 I know there are still some packages to port and fix Mar 16 15:40:27 NCommander: i can't reproduce this one: https://bugs.launchpad.net/ubuntu/+bug/618489 Mar 16 15:40:28 Launchpad bug 618489 in casper "[dove] casper fails to boot if SATA HDD is attached" [High,Fix released] Mar 16 15:40:35 NCommander: A0 board, sata hd attached Mar 16 15:41:00 ppisati: Fix released Mar 16 15:41:21 GrueMaster: in kernel too? Mar 16 15:41:31 GrueMaster: in casper he has workarounded it Mar 16 15:41:50 GrueMaster: in is_nice_device(), but if i take out that modification, my board still boot Mar 16 15:41:56 GrueMaster: it refuses to fail! :) Mar 16 15:42:24 So it was fixed in the kernel and the bug wasn't updated. Happens. Mar 16 15:42:30 GrueMaster: ok Mar 16 15:42:47 I remarked it. Mar 16 15:43:10 GrueMaster: let me just double check with Michael, then i close it Mar 16 15:43:36 He lives here, and hasn't worked on Dove since Maverick release. Mar 16 15:43:49 ah o Mar 16 15:43:50 k Mar 16 15:43:53 then i close it Mar 16 15:43:59 But I have mine set up and can do all the testing. Mar 16 15:44:13 GrueMaster: no, it's ok Mar 16 15:44:27 Just fyi, I am the QA guy for the canonical-arm team. Mar 16 15:44:33 GrueMaster: if you tell me that the fix was already committed, i'm fine with it Mar 16 15:44:57 Like I said, a lot of older bugs were fixed without updating LP. Mar 16 15:45:06 GrueMaster: ok Mar 16 15:45:23 Main test is if it can be reproduced with a released image or updates. Mar 16 15:45:42 GrueMaster: i used this one http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/release/ubuntu-netbook-10.10-netbook-armel+dove.img Mar 16 15:46:07 GrueMaster: opened squash, took out the casper workaround in is_nice_device() and repacked Mar 16 15:46:16 GrueMaster: and it worked Mar 16 15:46:29 Yep, that was the maverick released image. If a bug is based on that image, but prior to release and can't be reproduced on that image, it is usually been fixed. Mar 16 15:47:26 I have been trying to retest and close out older bugs recently. Mar 16 15:47:29 ppisati, repacking the squash is a no-op Mar 16 15:47:47 you need to re-roll the initrd *from* the unpacked squashfs Mar 16 15:47:52 its quite complex Mar 16 15:47:52 GrueMaster: to close a LP bug don't i need the sha? or i can just write "cannot reproduce it anymore, Tobin confirm it has already been fixed" and move it to "Fix released"? Mar 16 15:48:14 casper in the squashfs does nothing Mar 16 15:48:21 ogra: ok Mar 16 15:48:27 ogra: you are right, i'll do that Mar 16 15:48:28 Or you could mark it as invalid as not reproducible. Mar 16 15:50:09 ppisati: What type of marvell systems do you have? Mar 16 15:52:31 GrueMaster: mvl-dove A0 Mar 16 15:53:11 ok Mar 16 15:53:27 I want to make sure we have similar systems so I can help as needed. Mar 16 15:59:43 ogra: rerolled uInitrd and it works Mar 16 16:00:13 using update-initramfs -u inside the squashfs ? Mar 16 16:00:27 ogra: i'll tell you all the steps i took Mar 16 16:01:36 copied /casper/filesystem.squashfs from the my usb stick (where i previously i dd-ed the maverick mvl-dove img) to my box Mar 16 16:01:41 unsquashed it Mar 16 16:01:47 well, its essentially: unpack squashfs, mount proc and bindmount /dev, chroot into it ... Mar 16 16:02:01 copied qemu-arm-static to squash/usr/bin Mar 16 16:02:05 chrooted in it Mar 16 16:02:09 make your code change, run update-initramfs -u etc etc Mar 16 16:02:16 sounds like you took the right steps Mar 16 16:02:51 modified usr/share/initramfs-tools/scripts/casper Mar 16 16:03:04 and revrted the mvld-ve workaround Mar 16 16:03:06 then Mar 16 16:03:22 update-initramfs -u -k 2.6.32-410-dove Mar 16 16:03:30 mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d /boot/initrd.img-2.6.32-410-dove /boot/uInitrd Mar 16 16:03:42 right, sounds ok Mar 16 16:03:44 and finally copied uInitrd back to usb:/casper Mar 16 16:03:47 ok Mar 16 16:04:01 then i mark that bug as Invalid so we can close it Mar 16 16:04:14 i think tobin already marked it fixed Mar 16 16:04:36 ogra: the casper part, mvl-dove kernel was still pending Mar 16 16:04:49 and i'm trying to clean up as much as possible Mar 16 16:05:01 ah, k Mar 16 16:07:09 "This bug is not reproducible anymore in linux-mvl-dove, and after a bit of testing on IRC with Tobin and Oliver we concluded it has already been fixed. Closing it." Mar 16 16:07:49 sounds fine Mar 16 16:07:57 k, done Mar 16 16:08:22 ok, so now i have the 2 sound bugs and the rebase/-proposed pending Mar 16 16:08:22 cool Mar 16 16:31:25 phew ... finally Mar 16 16:32:02 so teleporter-glib should be installable again... and thus empathy Mar 16 16:32:13 GrueMaster, you should have images tomorrow again Mar 16 16:32:34 Yea, saw the update for telepathy. Mar 16 16:32:54 well, i wasnt sure it would build :) Mar 16 16:33:01 just finished fine Mar 16 17:29:25 ppisati: thebug itself was worked around in casper, but we had a task on thekernel due to change in name of the device **** ENDING LOGGING AT Thu Mar 17 02:59:57 2011