[12:36] <jadahl> when I try to install libc6:armel (on my x86_64-install) it says it depends on tzdata:armel. there is only tzdata:all, and it seems not being able to install because of this. to install libc and other libraries for cross compilation to ARM, is there other way of doing it? using xapt keeps forcing me to apt-get -f install removing g++ so not sure how to move forward with that tool
[13:43] <tedg> lool, Morning, heard that you might know something about valgrind on ARM? :-)
[13:43] <tedg> lool, We've got it failing to link on the dbusmenu build and I'm trying to figure out what's up.
[13:43] <tedg> https://launchpadlibrarian.net/98928961/buildlog_ubuntu-precise-armhf.libdbusmenu_0.5.96-0ubuntu1_FAILEDTOBUILD.txt.gz
[13:45] <tedg> lool, Sorry, xchat crashed.  If you responded, I missed it :-/
[13:54] <gildean> tedg: he didn't
[13:58] <lool> tedg: oy
[13:58] <tedg> lool, Heh, might thoughts exactly :-)
[13:58] <tedg> my
[14:01] <lool> tedg: I find it weird that it's mentioning /usr/lib/debug/usr/lib/arm-linux-gnueabihf
[14:01] <lool> ld shouldn't be poking there?!
[14:01] <tedg> lool, Could it be something funky with the pc file?  Do you have an ARM system handy?
[14:02] <tedg> Here's the x86 pkg-config
[14:02] <tedg> $ pkg-config --cflags --libs valgrind
[14:02] <tedg> -I/usr/include/valgrind  -L/usr/lib/valgrind -lcoregrind-amd64-linux -lvex-amd64-linux -lgcc
[14:02] <lool> tedg: Why do you actually need to link to valgrind?
[14:02] <lool> I dont see any valgrind include in the testapp
[14:02] <tedg> lool, It has a couple macros so that the startup/shutdown doesn't end up in the output.
[14:03] <tedg> lool, It's just including callgrind.h which is all one lib
[14:04] <lool> tedg: I'm not familiar with linking to valgrind, but from what I can tell, the build is failing to link tools/testapp/ which doesn't include callgrind.h or any valgrind header
[14:04] <lool> I've only run valgrind as a standalone tool myself
[14:05] <tedg> lool, Well, it sets up the pkgconfig setup for all the tests, they aren't done independently.
[14:05] <tedg> lool, So one of the tests uses it, but all of them get the link because the configure.ac is lazy (or it's authors, perhaps :-) )
[14:05] <lool> ah
[14:06] <lool> tedg: It's widespread practice to define the libs only once and then have all objects linked to them; it means you get superfluous lib deps on your binaries which get cleaned up after the fact by --as-needed; but that's unrelated, I guess this works on x86 and you expect it to work on ARM
[14:07] <tedg> lool, If it's helpful, the C file that uses the lib is test-json-server.c
[14:07] <lool> tedg: You could open a bug against valgrind in Ubuntu and/or upstream with a reduced testcase and poke linaro-toolchain@lists.linaro.org about it; the main upstream maintainer of valgrind is also on IRC and did the ARMv7 port himself, maybe we will help
[14:08] <lool> tedg: "sewardj"; I see he is connected to another IRC network at the moment
[14:09] <lool> tedg: I don't think the problem is with the use of valgrind that you have; it seems to be with valgrind object files on ARM when used for useless linking with random binaries (testapp doesn't use any valgrind foo)
[14:09] <tedg> lool, Okay, I'm just worried about hard freeze at this point.  I need to figure out if we need to drop the test in the packaging or we can fix it.
[14:10] <lool> tedg: You could try building the testcase and see whether *that* passes, if it does a workaround is to split valgrind CFLAGS and LIBS into their own VALGRIND_CFLAGS and VALGRIND_LIBS and only list them in LIBADD/LDADD where it actually matters (test-json-server.c)
[14:12] <lool> tedg: Or if you don't have time to try that out, make valgrind optional and don't list that test and that package on ARM (detect valgrind availability and pass --disable-valgrind if DEB_HOST_GNU_CPU is arm)
[14:12] <lool> tedg: I don't have good understanding of ELF on ARM or other valgrind subtelties to resolve this, but linaro-toolchain@ would likely be able to advise
[14:12] <tedg> lool, What's the name of the arm porter box?  Do we still have one?
[14:13] <tedg> lool, I can try a couple things there.
[14:13] <lool> tedg: We do have one; I believe there are now DNS aliases to connect to them
[14:13] <lool> tedg: porter-armhf.canonical.com
[14:16] <lool> tedg: it seems down though, ping IS?  I can telnet other porter boxes on port 22, but not the armel/armhf ones
[14:19] <tedg> lool, Okay, I will, sewardj might have a fix here...
[18:18] <ppisati> GrueMaster: you around?
[18:19] <GrueMaster> For the rest of the week.  sup?
[18:19] <ppisati> GrueMaster: cool, wait, i have a kernel for you
[18:19] <GrueMaster> For...what platform?
[18:20] <ppisati> panda
[18:20] <GrueMaster> I'm not actively testing panda any more.
[18:20] <ppisati> ah
[18:21] <GrueMaster> My focus atm is arm server only.
[18:21] <ppisati> k
[18:21] <GrueMaster> (and I'm not sure how much longer that will be).
[18:22] <ppisati> GrueMaster: but is you panda connected? i need a boot only test
[18:22] <ppisati> GrueMaster: or can you tell me if anyone is doing any testing at all on panda?
[18:23] <GrueMaster> ppisati: I was told all arm QA was being taken over by the QA team.  ask them.
[20:16] <Martyn> Has anyone seen David Mandala in the last day?
[20:19] <GrueMaster> Martyn: Try "ping davidm".