[08:57] ojn: Eh too bad you missed the give away === maen_afk is now known as maen [12:39] lool [13:01] saeed__: Yup [13:04] how can cross build kernel package for dove? [13:05] I tried: CROSS_COMPILE=arm-marvell-linux-gnueabi- CONCURRENCY_LEVEL=3 fakeroot make-kpkg --arch arm --initrd --append-to-version=-custom kernel_image kernel_headers --cross_compile - [13:19] Don't use make-kpkg [13:20] saeed__: http://kernel.ubuntu.com/ [13:20] saeed__: debuild/dpkg-buildpackage -e CROSS_COMPILE=arm-marvell-linux-gnueabi- should work [13:22] saeed__: https://help.ubuntu.com/community/Kernel/Compile [13:22] saeed__: Or http://idlethread.blogspot.com/2009/01/recipe-of-day-cross-compiling-armel.html [14:58] hmm, Mesa 7.6, anyone know of any plans to enable the GLES1/GLES2 part of it and provide packages? [15:05] Stskeeps: What for specifically? [15:05] I think we dont have userspace using GLES ATM; I think Clutter could use it but there are some bugs [15:05] lool: in this particular case, building against GLES2 headers and then drop in stuff like SGX [15:06] Right [15:06] (i'm aware there's some potential pitfalls in that) [15:07] I dont think we enable GLES support in mesa in karmic but I guess we could next cycle [15:07] :nod: [15:08] then there's also the issue of package naming, like, if it's libgles2-dev and so on :P [15:09] Looks like we just need to --enable-egl in a separate build [15:09] yeah, that was my thought [15:10] the effect is being able to do GLES stuff in public and fallback on sw rendering, .. and then be able to drop in GLES libs for your device's chip :P [15:26] hi [15:26] is there howto install ubuntu arm on a Nokia Internet Tablet? [15:27] thopiekar: just create rootfs with rootstock and install Mer hw-support stuff :) [15:27] thanks, Meiz_webchat [15:41] does anyone of you know how large the size of the rootfs should be to install it on the flash memory? [16:47] hmm I wanted to create now a rootfs with rootstock but it uses jaunty.. [16:47] I created myself a karmic chroot [16:47] with kubuntu-netbook installed.. [16:48] is there a way to get that chroot as a rootfs? === Tscheesy is now known as with_Tscheesy === with_Tscheesy is now known as Tscheesy === Tscheesy is now known as Tscheesy_ [20:11] ojn : where did ARM/Freescale hand out the pegatron netbooks? === Meiz_TB is now known as Meizirkki === Meizirkki is now known as Meiz_TB === Meiz_TB is now known as Meiz__TB === Meiz__TB is now known as Meiz___TB === Meiz___TB is now known as Meiz_TB [22:33] hi, what is the /lib/vfp directory?? , why it is installed on my target? some of my .so files resides there as well as at /lib/ - and they are different. any idea? [22:36] /vfp is probably for binaries compiled with vfp support [22:36] https://lists.ubuntu.com/archives/jaunty-changes/2009-March/007966.html [22:38] related: http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg1395037.html [22:44] Thanks. but i didn't understand why it was added?, why all the files are in different size than the same files in /lib or /usr/lib ? [22:45] probably because they use vfp instructions to speed up floating-point calculation [22:48] well, on my host, when cross-compiling, my libraries were taken from /lib and /usr/lib, but on the target applications use /lib/vfp , I guess this is a good reason for problems. Is there a recommendation what to use? [22:53] um, shouldn't you have a separate tree with libs for the target system? [22:54] you should probably either disable vfp when compiling, or install/crolss-compile vfp libs on the host system... [22:57] actually, on the host I was used a copy of the target filesystem (using relative symbolic links) and pointing the LIBDIR to either /lib or /usr/lib. But then when executing on the target the application was loading the libs from /lib/vfp... [22:57] can I be sure that every library installed in /lib or /usr/lib is also installed in vfp ? [22:58] i think it will fall back to /lib if it's not found in vfp... [23:01] so i need to define both paths for linking?, is there a way to define it with priorities?. I have to say that this issue sounds not convenient at all. i will try playing with that... [23:02] maybe try running the program with LD_HWCAP_MASK=0x0 and see if it helps [23:04] beyossi: We built two passes of glibc in jaunty [23:04] One for vfp and one for non-vfp [23:04] The versioning between the two on an installed system is very strict [23:12] lool: for example, libdl.so.2 is taken from the /lib/vfp library (monitoring using ldd), while the same file name exist at /lib/libdl.so.2 - the libdl.so is at: /usr/lib/libdl.so and it points to ../../lib/libdl.so.2 . so i don't understand why the program is using /lib/vfp [23:20] black magic [23:21] i guess ld is checking hwcaps and adding /vfp to search path if hardware supports it [23:23] but as far as I understand, a program will look for libdl.so (which exists only once) and not directly to libdl.so.2, and my libdl.so points to a specific place [23:27] btw, I renamed library /lib/vfp to /lib/vfp2 and then everything points back to the 'old places' - latter on I will try building my entire target with the vfp [23:27] Thanks for your help [23:32] Another issue I face is related to executing QT on my beagleboard which has a PowerVR GPU. after executing the app it fails with: "powervr: driver not found", does anybody know what drivers it looks for exactly?, anyway to debug it?