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