[12:28] <sebjan> Hi, while testing the Natty Alpha2 image on panda, I need to run a 'sudo dhclient -4 usb0' to get an IPv4 allocated (else, I seem to have an IPv6 only). Is this expected / known behavior?
[12:41] <ogra> not expected and i dont see it on my panda
[12:41] <ogra> NM just does what it's supposed to
[12:54] <sebjan> ogra: I don't see the nm-applet in the bar, and ifconfig does not provide a IPv4. after the above trick, I can get a network connection through usb0, but still do not see the nm-applet (I'd like to configure my wlan connection with in in fact)
[13:05] <rsalveti> sebjan: check if you have nm-applet running, if so then check if the network manager daemon is running
[13:06] <rsalveti> otherwise it's not going to show itself at the bar
[13:06] <sebjan> rsalveti: nm-applet is running actually, but not hint on network-manager (it shall be called like this?)
[13:07] <rsalveti> sebjan: NetworkManager
[13:09] <sebjan> rsalveti: ok, not running either
[13:09] <sebjan> I suspect that it fails to run properly since I activated the wlan: I need to make some tricks to be able to use the wlan, and this may upset network manager...
[13:09] <rsalveti> sebjan: try service network-manager start
[13:10] <rsalveti> could be
[13:10] <rsalveti> sebjan: run NetworkManager --no-daemon --log-level=DEBUG
[13:10] <rsalveti> then you can check why it's failing
[13:11] <sebjan> rsalveti: ok, thanks, I'll do that
[13:24] <ogra> sebjan, and make soure you didnt touch /etc/network/interfaces ;)
[13:24] <ogra> else NM will ignore your interface
[13:35] <sebjan> damn, network manager segfaults...
[13:38] <rsalveti> sebjan: are you using maverick?
[13:38] <sebjan> rsalveti: no, Natty alpha2
[13:41] <rsalveti> sebjan: hm, if you didn't update than this maybe fixed already with latest upload
[13:41] <rsalveti> sebjan: we had some issues and instabilities with NM during the alpha2 time
[13:42] <sebjan> right, I will make an upgrade: I just see that during gdm start, network manager is started/dies/re-started/dies/...
[17:38] <slangasek> rsalveti: hi there!  we're looking at the question of building qt4-x11 with gles2 enabled on armel instead of opengl; if we did this in the official package in natty, do you know if that would cause regressions?
[17:39] <slangasek> i.e.: I don't think there are any accelerated full-opengl drivers available in Ubuntu, but I know we have gles2 for panda, so it's a win there... but what about unaccelerated systems?
[17:39] <rsalveti> slangasek: would affect some kde packages, and some others from universe
[17:39] <slangasek> affect them adversely?
[17:40] <slangasek> is that because it would introduce ABI changes, or for other reasons?
[17:40] <rsalveti> bug 707794
[17:40] <ubot2> Launchpad bug 707794 in qt4-x11 "libqt4-opengl on armel should be compiled with OpenGL ES 2.x support" [Undecided,Confirmed] https://launchpad.net/bugs/707794
[17:40] <rsalveti> slangasek: the main problems is a conflict that happens when you have an application that needs GL and uses libqt4-opengl
[17:40] <rsalveti> once we build qt with the gles backend, the symbols will conflict
[17:41] <slangasek> symbol collision> oh, interesting
[17:41] <rsalveti> because Qt lets the user to use GL directly, together with Qt
[17:41] <slangasek> yes
[17:42] <slangasek> so those libraries should really have symbol versions applied, but I guess that may technically be a violation of the standard ABI
[17:42] <slangasek> thanks for the bug reference.  Do you know of any issues besides what's mentioned in that bug?
[17:43] <slangasek> worst case, we will probably provide a gles2 build in our ppa for this cycle
[17:43] <slangasek> but I would like to dig deeper to see if we can resolve the symbol problem for the short term, without compromising future development work on the proxy library
[17:44] <rsalveti> slangasek: for the moment I believe having it on a ppa should be enough
[17:44] <rsalveti> the problem of sharing many symbols
[17:45] <rsalveti> and also, if you link with libqt4-opengl it'll bring EGL and GLES2
[17:45] <rsalveti> headers collision and more
[17:48]  * ogra would really like to see the core libs to be GLES on arm ... ignoring the few packages that will break until they are fixed properly
[17:48] <slangasek> it's "enough", but ppas are only 2GB and if we put qt4 in our linaro overlay ppa, that's a good chunk gone :)
[17:49] <ogra> imho its a failure of the apps to be programmed in a broken way
[17:50] <rsalveti> well, Qt gives you the liberty to use GL together with Qt
[17:50] <rsalveti> and also support different backends
[17:50] <ogra> how about having a libqt4-gles ?
[17:50] <rsalveti> so it's not something like clutter, that you only use the clutter API
[17:51] <ogra> (arm only indeed)
[17:51] <rsalveti> ogra: and in what that will help us?
[17:51] <rsalveti> then we would need to change all the packages we want to link with the new libqt4-gles package
[17:52] <ogra> yes, it would need some buildd sided magic i guess
[17:52] <rsalveti> and probably need some work in qt to generate both libs without many issues
[17:52] <rsalveti> without having 2 different qts in the archive
[17:52] <ogra> yes
[17:53] <slangasek> no, building libqt4-gles is not a good solution
[17:53] <ogra> its surely a lot of work (and surely nothing for natty)
[17:53] <rsalveti> that's why having it on a ppa would be easier for the moment
[17:53] <rsalveti> while we don't have the proxy lib and the gles support for glew
[17:53] <slangasek> I'm going to have a look at symbol versioning on the gles2 side
[17:53] <ogra> i would still prefer to rather ignore the handfull of apps
[17:54] <slangasek> as a fallback, we might disable the opengl-needing packages in discussion with the Kubuntu team
[17:54] <rsalveti> yup
[17:54] <ogra> ++
[17:55] <rsalveti> software rendering with opengl on arm is basically having nothing
[17:55] <rsalveti> very very slow
[17:55] <rsalveti> so, no use
[17:55]  * slangasek nods
[17:55]  * ogra disagrees :)
[17:55] <ogra> you should see composite on framebuffer here on the ac100
[17:56] <ogra> no noticeable difference to non-composite metacity
[17:56]  * hrw confirms
[17:56] <rsalveti> hm, cool, good to know :-)
[17:56] <ogra> seems to depend on the HW :)
[17:57] <hrw> ogra: how fast is membus on ac100?
[17:57] <ogra> 400MHz ?
[17:57] <ogra> not sure
[17:57] <hrw> ok
[18:42] <GrueMaster> So, the image doesn't have initrd.img in /boot on the second partition.  Why?
[19:12] <vinay__> Hello, I am trying to get cross-compiling environment (including autotools) for Arm on Ubuntu 10.04. What is the best way to proceed?
[19:43] <rsalveti> GrueMaster: probably something is broken at the update-initramfs part
[19:43] <rsalveti> or the hook while installing the kernel
[19:55] <GrueMaster> The uImage is on the boot partition, and there is a link in /boot, but no actual file.
[20:05] <rsalveti> so it could be a problem at the update-initramfs
[20:05] <rsalveti> try mounting and installing with qemu
[20:06] <rsalveti> to see if the the update-initramfs is called at the postinst
[20:51] <GrueMaster> rsalveti: It is something with the image generation.  uImage wouldn't exist if update-initramfs failed.
[20:52] <GrueMaster> And it works fine on an installed image.