=== wgrant_ is now known as wgrant | ||
=== asac_ is now known as asac | ||
=== ogra_ is now known as ogra | ||
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:28 |
---|---|---|
ogra | not expected and i dont see it on my panda | 12:41 |
ogra | NM just does what it's supposed to | 12:41 |
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) | 12:54 |
rsalveti | sebjan: check if you have nm-applet running, if so then check if the network manager daemon is running | 13:05 |
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:06 |
rsalveti | sebjan: NetworkManager | 13:07 |
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:09 |
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:10 |
sebjan | rsalveti: ok, thanks, I'll do that | 13:11 |
ogra | sebjan, and make soure you didnt touch /etc/network/interfaces ;) | 13:24 |
ogra | else NM will ignore your interface | 13:24 |
sebjan | damn, network manager segfaults... | 13:35 |
rsalveti | sebjan: are you using maverick? | 13:38 |
sebjan | rsalveti: no, Natty alpha2 | 13:38 |
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:41 |
sebjan | right, I will make an upgrade: I just see that during gdm start, network manager is started/dies/re-started/dies/... | 13:42 |
=== XorA|gone is now known as XorA | ||
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:38 |
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:39 |
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:40 |
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:41 |
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:42 |
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:43 |
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:44 |
rsalveti | and also, if you link with libqt4-opengl it'll bring EGL and GLES2 | 17:45 |
rsalveti | headers collision and more | 17:45 |
* 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:48 |
ogra | imho its a failure of the apps to be programmed in a broken way | 17:49 |
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:50 |
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:51 |
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:52 |
=== Willie is now known as Guest25756 | ||
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:53 |
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:54 |
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:55 |
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:56 |
=== Tscheesy_ is now known as Tscheesy | ||
hrw | ogra: how fast is membus on ac100? | 17:57 |
ogra | 400MHz ? | 17:57 |
ogra | not sure | 17:57 |
hrw | ok | 17:57 |
=== XorA is now known as XorA|gone | ||
=== Tscheesy_ is now known as Tscheesy | ||
GrueMaster | So, the image doesn't have initrd.img in /boot on the second partition. Why? | 18:42 |
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:12 |
rsalveti | GrueMaster: probably something is broken at the update-initramfs part | 19:43 |
rsalveti | or the hook while installing the kernel | 19:43 |
GrueMaster | The uImage is on the boot partition, and there is a link in /boot, but no actual file. | 19:55 |
rsalveti | so it could be a problem at the update-initramfs | 20:05 |
rsalveti | try mounting and installing with qemu | 20:05 |
rsalveti | to see if the the update-initramfs is called at the postinst | 20:06 |
GrueMaster | rsalveti: It is something with the image generation. uImage wouldn't exist if update-initramfs failed. | 20:51 |
GrueMaster | And it works fine on an installed image. | 20:52 |
=== Amaranth_ is now known as Amaranth | ||
=== nslu2-log is now known as 5EXAB8AF3 | ||
=== ericm|ubuntu is now known as 5EXAB9OY8 | ||
=== fta` is now known as fta | ||
=== alf is now known as 5EXAB9WD8 | ||
=== 5EXAB9WD8 is now known as alf |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!