[08:57] <lool> ojn: Eh too bad you missed the give away
[12:39] <saeed__> lool
[13:01] <lool> saeed__: Yup
[13:04] <saeed__> how can cross build kernel package for dove?
[13:05] <saeed__> 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] <lool> Don't use make-kpkg
[13:20] <lool> saeed__: http://kernel.ubuntu.com/
[13:20] <lool> saeed__: debuild/dpkg-buildpackage -e CROSS_COMPILE=arm-marvell-linux-gnueabi- should work
[13:22] <lool> saeed__: https://help.ubuntu.com/community/Kernel/Compile
[13:22] <lool> saeed__: Or http://idlethread.blogspot.com/2009/01/recipe-of-day-cross-compiling-armel.html
[14:58] <Stskeeps> hmm, Mesa 7.6, anyone know of any plans to enable the GLES1/GLES2 part of it and provide packages?
[15:05] <lool> Stskeeps: What for specifically?
[15:05] <lool> I think we dont have userspace using GLES ATM; I think Clutter could use it but there are some bugs
[15:05] <Stskeeps> lool: in this particular case, building against GLES2 headers and then drop in stuff like SGX
[15:06] <lool> Right
[15:06] <Stskeeps> (i'm aware there's some potential pitfalls in that)
[15:07] <lool> I dont think we enable GLES support in mesa in karmic but I guess we could next cycle
[15:07] <Stskeeps> :nod:
[15:08] <Stskeeps> then there's also the issue of package naming, like, if it's libgles2-dev and so on :P
[15:09] <lool> Looks like we just need to --enable-egl in a separate build
[15:09] <Stskeeps> yeah, that was my thought
[15:10] <Stskeeps> 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] <thopiekar> hi
[15:26] <thopiekar> is there howto install ubuntu arm on a Nokia Internet Tablet?
[15:27] <Meiz_webchat> thopiekar: just create rootfs with rootstock and install Mer hw-support stuff :)
[15:27] <thopiekar> thanks, Meiz_webchat
[15:41] <thopiekar> does anyone of you know how large the size of the rootfs should be to install it on the flash memory?
[16:47] <thopiekar> hmm I wanted to create now a rootfs with rootstock but it uses jaunty..
[16:47] <thopiekar> I created myself a karmic chroot
[16:47] <thopiekar> with kubuntu-netbook installed..
[16:48] <thopiekar> is there a way to get that chroot as a rootfs?
[20:11] <Martyn> ojn : where did ARM/Freescale hand out the pegatron netbooks?
[22:33] <beyossi> 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] <roxfan> /vfp is probably for binaries compiled with vfp support
[22:36] <roxfan> https://lists.ubuntu.com/archives/jaunty-changes/2009-March/007966.html
[22:38] <roxfan> related: http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg1395037.html
[22:44] <beyossi> 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] <roxfan> probably because they use vfp instructions to speed up floating-point calculation
[22:48] <beyossi> 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] <roxfan> um, shouldn't you have a separate tree with libs for the target system?
[22:54] <roxfan> you should probably either disable vfp when compiling, or install/crolss-compile vfp libs on the host system...
[22:57] <beyossi> 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] <beyossi> can I be sure that every library installed in /lib or /usr/lib is also installed in vfp ?
[22:58] <roxfan> i think it will fall back to /lib if it's not found in vfp...
[23:01] <beyossi> 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] <roxfan> maybe try running the program with LD_HWCAP_MASK=0x0 and see if it helps
[23:04] <lool> beyossi: We built two passes of glibc in jaunty
[23:04] <lool> One for vfp and one for non-vfp
[23:04] <lool> The versioning between the two on an installed system is very strict
[23:12] <beyossi> 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] <roxfan> black magic
[23:21] <roxfan> i guess ld is checking hwcaps and adding /vfp to search path if hardware supports it
[23:23] <beyossi> 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] <beyossi> 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] <beyossi> Thanks for your help
[23:32] <beyossi> 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?