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