[01:11] <Kurlon> Any chance I could boot an ubuntu arm userland with an Android kernel?
[01:11] <Kurlon> Or are they too butchered?
[02:47] <rsalveti> Kurlon: you can, not that will work 100% fine, but most of the times you can enable later what's missing
[02:47] <rsalveti> I think the ac100 kernel is still the android one
[02:47] <rsalveti> and people are using it mostly with ubuntu
[04:40] <lilstevie> the one I use with the tab is still an android butchered kern
[04:40] <lilstevie> but too much is broke
[04:40] <lilstevie> and I have to start rolling back some of the android patches
[04:41] <lilstevie> which is proving rather troublesome
[04:50] <rsalveti> it all depends on the quality of the changes
[04:51] <rsalveti> if it's not breaking stuff at least, you can still use a config compatible with ubuntu
[04:51] <rsalveti> with the needed modules and stuff
[09:49] <ogra> hrm
[09:50] <ogra> no images :(
[09:50] <ogra> bug 721118
[09:50] <ubot2> Launchpad bug 721118 in unity "Unity FTBFS on armel due to Nux" [High,Fix committed] https://launchpad.net/bugs/721118
[10:04] <XorA_> morning
[10:46] <ericb2> hello
[10:46] <ericb2> I'm using the natty version on BeagleBoard xM and it's slow
[10:46] <ericb2> is the proc frequency 600 MHz only ?
[10:47] <ericb2> second, looks like there is no 3D acceleration. Is there something possible, or ..
[10:47] <ericb2> thanks in advance :)
[10:52] <ogra> i think there is some cmdline option you can set to make it operate on full speed
[10:53] <ericb2> ogra: I believed cpufreq-selector could help, but the frequency management is not handled (if I searched correctly)
[10:53] <ogra> and the sgx drivers should be in multiverse somewhere
[10:54] <ericb2> ogra: ah, thanks. was the name missing me
[10:54] <ericb2> sgx
[11:03] <XorA_> I think you do mpurate=<number> to get itr faster
[11:03] <ericb2> XorA_: at boot time ?
[11:03] <XorA_> ericb2: yes
[11:03] <ericb2> XorA_: ok. and what number are possibles ?
[11:04] <ericb2> numbers
[11:04] <ogra> i think it takes MHz values
[11:04] <ogra> so 1000 should get you a GHz
[11:04] <ericb2> ok, I'll try 800 then
[11:04] <XorA_> 800 certainly safe if thats the right arg, Im working from memory
[11:04]  * XorA_ only got an XM yesterday
[11:05]  * ogra imagines 1000 should work too, buut 800 is surely safer
[11:05] <ericb2> ok. anyway, we'll see
[11:05] <ericb2> is there a key to hit at boot ?
[11:06] <XorA_> I think koen was running XM happilly at 1.2Ghz
[11:06] <ogra> no, you edit /boot/boot.script and run sudo flash-kernel
[11:06] <ogra> on the running system
[11:06] <ogra> that will change your boot args
[11:07] <ericb2> ogra: thanks
[11:08]  * XorA_ shall Natty his XM tonight
[11:08] <ogra> heh
[11:09] <ogra> i think we shopuld probably set mpurate at image buildtime
[11:09] <janimo> ogra, ping
[11:09] <ogra> the prob is that these images also run on B and C series beagles and we cant really determine if we are on a XM
[11:10] <ogra> janimo, yo
[11:10] <XorA_> the cpufreq patches should be mainstream now, and they know what type of omap you have
[11:10] <ogra> janimo, in bug 724615 there is a "fix committed" set, could you please link the branch in the future ? (desktop team asked)
[11:10] <ubot2> Launchpad bug 724615 in unity "unity FTBFS on armel" [High,Fix committed] https://launchpad.net/bugs/724615
[11:11] <XorA_> but last I saw there were some bugs in cpufreq framework preventing going to full speed as it assume unique voltages for each frequency
[11:11] <ogra> that way its easier to find what the patch was :)
[11:11] <ericb2> XorA_ I got an xM rev 1 if I'm not wrong
[11:12] <XorA_> dont know which rev I got
[11:12] <ogra> no sticker ?
[11:13] <XorA_> ogra: its at home, my eyesight not that good
[11:13] <ogra> train it !
[11:13] <XorA_> someone sold it to me cheap over the weekend
[11:13]  * XorA_ never persuaded TI to part with any :-D
[11:15] <ericb2> shit I tried to install libgl1-sgx-omap3 libgles2-sgx-omap3 and  it fails.
[11:15] <ericb2> the reason is  : FATAL:  module omaplfb not found
[11:16] <ogra> you need the powervr package first i think
[11:16] <ogra> powervr-omap3-dkms
[11:16]  * ericb2 tries
[11:17] <ericb2> it is already installed
[11:18] <ericb2> Building ...
[11:18] <ogra> is it done compiling already ?
[11:18] <ogra> aha
[11:18] <ericb2> Error! Bad return status for module build on kernel: 2.6.38-1-omap (armel)
[11:18] <ericb2> I'll consult the make.log
[11:19] <ogra> is that your own kernel ?
[11:19] <ericb2> ogra: no it isn't
[11:19] <ericb2> error : unknown fiels 'ioctl' specified in initializer
[11:19] <ogra> hmm, strange
[11:19] <ericb2> s/fiels/field/
[11:20] <ogra> there might be a ppa where rsalveti provides an update package, wait until he is around
[11:20] <ericb2> in build/services4/3rdparty/bufferclass_ti/bc_cat.c
[11:20] <ogra> though i'm not sure he rolled a new one for omap3 ... i know there is one for omap4 somewhere
[11:21] <janimo> ogra, there was no branch I committed to trunk
[11:21] <janimo> there's a ton of ubnity email since I am on the team, so I would not be surprised commit messages to be overlooked
[11:21] <ogra> janimo, then make a branch first and link it or attach a patch or some such
[11:22] <ogra> its just very hard to find out about the fix if nothing is linked
[11:22] <ogra> you can even just copy the link to the revision into a comment
[11:23] <janimo> ok, I was hoping that bzr commit would do something as I inlucde dLP :#XXX in the commit msg
[11:23] <ogra> hmm
[11:23] <janimo> is this on ayatana or u-desktop?
[11:23] <ogra> i think it should ... i rarely cimmit to upstream branches directly though, i usually link merge branches
[11:24] <ogra> the discussion was on u-desktop
[12:24] <ericb2> ogra: is it possible to compile by hand ?
[12:24] <ogra> look up the dkms docs, i think you can trigger it by hand
[12:25] <ericb2> ogra: I'm currently in /var/lib/dkms/pwervr-omap3/3.01.00.07/build/services4/3rdparty/bufferclass_ti, but make leads me to undefined $KERNEL_DIR
[12:25]  * ericb2 looks
[12:26] <ogra> hmm, really looks like you dont use the official kernel
[12:26] <ericb2> ogra: no idea : Im running the Ubuntu image I found the link on the Ubuntu wiki
[12:26] <ericb2> ogra: this is natty, could be related ?
[12:27] <ogra> linux-image-2.6.38-5-omap
[12:27] <ogra> thats the version you should have installed
[12:27] <ericb2> ogra:  uname  -a tells : Linux beagle 2.6.38-1-omap
[12:28] <ericb2> ogra:  uname  -a tells : Linux beagle 2.6.38-1-omap #28-Ubuntu
[12:28] <ogra> that sounds outdated
[12:29] <ericb2> indeed, apt-cache tells me about 2.6.38-5
[12:31] <ericb2> shit .. no network
[12:32] <ericb2> is /etc/init.d/networking restart wrong  ?
[12:32] <ogra> that only restarts low-level bits iirc
[12:32] <ogra> network manager cares for the higher level bits
[12:33] <ericb2> ogra: and I need to got X.org running for that ?
[12:33] <ogra> you can also set it up in /etc/network/interfaces instead
[12:34] <ogra> then NM will use the config from there without X
[12:41] <ericb2> I added two lines in /etc/network interfaces :   allow-hotplug usb0  and   iface usb0  inet dhcp
[12:41] <ericb2> and ifup usb0 fails
[12:41] <ogra> and auto usb0 ?
[12:41] <ogra> you shouldnt need allow-hotplug
[12:41] <ogra> cat /proc/net/dev|grep usb ?
[12:43]  * ericb2 removed allow-hotplug an retries ...
[12:45] <ericb2> ogra: got :  usb0: 64009 677 .... and so on
[12:45] <ogra> looks fine
[12:45] <ericb2> ok, works now. Suddenly ...
[12:46] <ogra> its magic :)
[12:47] <ericb2> ogra: ufff ... loosk like I'm in debug mode ... got  zillions of [ xxxx.xxxxxx]  smsc95xx 1-2.1:1.0: usb0: kevent 2 may have been dropped
[12:48]  * ericb2 installing kernel 2.6.38-5 
[12:49] <ericb2> (omap version)
[12:53]  * ericb2 hopes to be able to work a bit today 
[13:03] <rsalveti> morning
[13:05] <ericb2> rsalveti: hi
[13:05] <ericb2> rsalveti: got a problem installing powervr on omap3
[13:05] <ericb2> rsalveti: X.org is gone ...
[13:06] <ericb2> rsalveti: + the build fails
[13:06] <rsalveti> ericb2: could be that sgx is broken with latest updates
[13:06] <rsalveti> ericb2: can you open a bug against it?
[13:06] <rsalveti> will take a look then
[13:06] <ericb2> rsalveti: where ?
[13:06] <ericb2> rsalveti: do you have a link I meant
[13:06] <rsalveti> maybe by updating the package or by fixing the current code
[13:07] <rsalveti> ericb2: just open a bug agains the sgx package for omap3
[13:07] <rsalveti> putting your dkms logs
[13:07] <rsalveti> ericb2: there's a workaround to avoid the smsc95xx messages
[13:07] <rsalveti> let me get the link
[13:08] <rsalveti> XorA: ogra: and for omap I'd like to merge the patch that sets the mhz higher for most beagle boards
[13:09] <rsalveti> also on my todo, was waiting more discussion and see if it'd go for 39
[13:09] <rsalveti> than I can easily backport for our current 38
[13:10] <gholl> does anyone know how long i can expect to wait for the image writing to complete? I'm following instructions here for a beagle board install, https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
[13:11] <rsalveti> ericb2: for smsc messages: Add to /etc/sysctl.conf: vm.min_free_kbytes = 8192
[13:12] <ericb2> rsalveti: ok, I'll do once I'll have installed kernel-sources for 2.6.38-5
[13:12] <rsalveti> ericb2: thanks
[13:14] <ericb2> btw, mpurate=800 seems to work well. mpurate=1000 does nothing, and looks like 600 MHz is the fallback
[13:15]  * ericb2 doing everything on a simple 16GB micro SD card 
[13:15] <ogra> k
[13:16] <ericb2> would be fantastic to find 32 or even 64GB a day, using such "size"  :)
[13:16] <ericb2> 1cm square hard disk is a bit of fun
[13:16] <XorA_> crap just reminded me I dont have any high speed microSDs
[13:34] <ericb2> rsalveti: done. ( /etc/sysctl.conf ..etc)
[13:46] <ericb2> rsalveti: https://bugs.launchpad.net/ubuntu/+source/powervr-omap3/+bug/726541
[13:46] <ubot2> Launchpad bug 726541 in powervr-omap3 "powervp installation broken on aremel (kernel 2.6.38-5)" [Undecided,New]
[13:48] <rsalveti> ericb2: cool, thanks
[13:49] <ericb2> rsalveti: I added one comment
[13:50] <ericb2> rsalveti: wiating, what can I do to repair my X.org (currently broken)
[13:50] <ericb2> ?
[13:50] <ericb2> s/wiating/waiting/
[13:50] <rsalveti> ericb2: what happened to your x.org?
[13:51] <ericb2> something like "module omaplfb not found" or something close
[13:51] <ericb2> rsalveti: happened when I tried to install powervr
[13:52] <ericb2> and apt-cache search omaplfb    ... is empty :/
[13:52] <rsalveti> that's because this module is loaded during the sgx initscript
[13:53] <rsalveti> but it shouldn't affect your xorg
[13:53] <rsalveti> as the omap 3 driver doesn't properly support the xorg
[13:53] <ericb2> rsalveti: where is the config file located ? Maybe I can reconfigure X.org ?
[13:55] <rsalveti> ericb2: there's no xorg conf by default
[13:55] <ericb2> rsalveti: sorry, how does it work then ?
[13:55] <rsalveti> ericb2: at /usr/share/X11/xorg.conf.d are the basic confs, but not something that sets your video driver
[13:56] <rsalveti> you can still create your own config, but not needed
[13:56] <rsalveti> as you're basically using xorg with framebuffer
[13:57] <ericb2> rsalveti: ok, and how can I figure out what happens ? The only info I got is  :  ddxSigGiveUp : Closing log
[13:57] <ericb2> in /var/log/Xorg.0.log
[13:57] <rsalveti> ericb2: can you post your x.org log for me?
[13:59] <ericb2> rsalveti: yes, sure. Let me try to launch it manually
[14:00] <ericb2> (EE} HID 04f3:013: failed to initialize for relative axes.
[14:01] <ericb2> could the mpurate=800 be the reason ?
[14:06] <ericb2> and servce gdm restart does notthing ... tested on CTRL + ALT + F6 -> F10
[14:08] <rsalveti> if xorg is failing, then gdm restart will not work
[14:08] <ericb2> rsalveti: I know. Was to obtain a track, somewhere to search
[14:18] <ericb2> rsalveti: the only track I got, is when I installed the libegl1-sgx-omap3 lib, a lot of libs have been uninstalled
[14:19] <ericb2> rsalveti: bingo
[14:19] <ericb2> rsalveti: broken dependencies
[14:20] <rsalveti> it's normal to remove some mesa libraries and dependencies, as the sgx one will replace them
[14:20] <rsalveti> but it could be that something was remove accidentally
[14:20] <rsalveti> *removed
[14:21] <rsalveti> I'm setting up my beagleboard to test the package again
[14:21] <rsalveti> and try to fix it
[14:21] <ericb2> rsalveti: you mean everyting removed +  omaplfb module should replace everything ?
[14:21]  * ericb2 will redo .. not clear 
[14:21] <rsalveti> no, the sgx packages should replace the libegl/libgles from mesa
[14:21] <rsalveti> and when the mesa packages are removed, some others are also removed, as not used anymore
[14:22] <ericb2> rsalveti: ok, but sgx package won't work without the module ?
[14:22] <rsalveti> ericb2: nops
[14:22] <ericb2> rsalveti: ah .. sorry looks I'm plain wrong
[14:22] <rsalveti> but your xorg should still work
[14:23] <ericb2> rsalveti: it's not the case
[14:30] <lag> rsalveti: Did you manage to give that rootfs a stab?
[14:31] <rsalveti> lag: argh, sorry, it took so long to download that I completely forgot
[14:31] <rsalveti> let me dig it here
[14:32] <lag> :)
[14:32] <lag> np
[15:18] <rsalveti> lag: did you try this rootfs with kernel upstream?
[15:18] <rsalveti> or how are you planning to use it?
[15:19] <lag> rsalveti: I have various kernels I can try to use it with
[15:19] <lag> rsalveti: The main one is on git.linaro.org
[15:19] <rsalveti> lag: so what exactly you want me to test with it?
[15:19] <lag> rsalveti: I'm guessing you don't have HW though
[15:19] <lag> Anything?
[15:19] <rsalveti> just to try it with beagle?
[15:19] <rsalveti> ok
[15:20] <lag> rsalveti: I think it's just a generic kernel
[15:20] <lag> Sure
[15:39] <XorA_> hey prpplague
[15:39] <prpplague> XorA_: hey bud
[15:40] <XorA_> prpplague: what happens if I plug a zippy into beagle XM?
[15:41] <prpplague> XorA: it goes *poof*
[15:41]  * prpplague jokes with XorA 
[15:41] <XorA_> :-(
[15:41] <prpplague> XorA: zippy and zippy2 have been tested with xm with no issues
[15:42] <XorA_> prpplague: sweet, even bigger rootfs with LVM then :-D
[17:54] <rsalveti> lag: image is working fine
[17:54] <rsalveti> lag: with our 38 for omap
[17:54] <rsalveti> linaro image but still "Welcome to Ubuntu Natty" :-)
[18:17] <lag> rsalveti: It's the Linaro image of Ubuntu
[18:17] <ogra> heh
[18:18] <ogra> "the linaro image of ubuntu"
[18:18] <ogra> sounds like "the duke of earl"
[18:21] <janimo> rsalveti, do TI plan a .38 upload now that it seems to be close to good enough?
[18:22] <ogra> TI ... upload ... ?
[18:23] <ogra> janimo, cooloney does our kernel, whenever he is ready we should get a package
[18:23] <ogra> given that there are only a few hours until freeze i wouldnt expect it before alpha3 though
[18:23] <janimo> ogra, ah great. Well, green light for upload, pull request whatever :)
[18:24] <janimo> it's a soft freeze :)
[18:24] <armin76> ogra talking bad about TI *g*
[18:24] <ogra> k, i'll try to ping him tomorrow morning
[18:24] <janimo> and it does not go into images so should not destabilize A3
[18:24] <ogra> we wont have parallel kernel packages for omap4
[18:25] <janimo> ah, so it's a straigh update
[18:25] <ogra> so it has to be good enough to replace the existing one
[18:25] <janimo> ok, then
[18:25] <ogra> right
[18:25] <ogra> kernel team refused to maintain two packages
[18:25] <janimo> makes perfect sense
[18:25] <ogra> specially since we would get naming probs
[18:25] <ogra> and cross-grading would become a pain
[18:26] <janimo> ogra, what were the takeaways from the emdebian meeting?
[18:26] <janimo> anything new to us?
[18:26] <rsalveti> janimo: ogra: new .38 upload should be done when cooloney work on it
[18:26] <rsalveti> but, still not tested
[18:26] <ogra> rsalveti, right
[18:26] <rsalveti> the pull request is done from TI side already
[18:27] <ogra> i think janimo just said it was good for him above
[18:27] <janimo> ok
[18:27] <ogra> yup, i saw the mail
[18:27] <ogra> the sound stuff doesnt look convincing though
[18:27] <ogra> but we have time to fix that this time (i hope)
[18:27] <rsalveti> yeah
[18:27] <rsalveti> I believe we'll go a3 with the kernel we have in hands
[18:28] <rsalveti> this new on a ppa and after a3 we can do the switch
[18:28] <ogra> yeah
[18:28] <rsalveti> as the soft freeze for a3 is today
[18:28] <rsalveti> wasn't expecting that
[18:28] <ogra> freeze is at 23:00 UTC
[18:28] <armin76> where is that .38 kernel coming from?
[18:28] <rsalveti> yeah
[18:28] <rsalveti> armin76: from TI
[18:28] <ogra> its always on mondy evening/tuesday morning
[18:28] <rsalveti> armin76: but basically the same one linaro currently delivers
[18:28] <rsalveti> ogra: yeah, was expecting it to be tomorrow, but fine :-)
[18:29] <rsalveti> nothing urgent
[18:29] <ogra> well, looks like unity didnt make it yet
[18:29] <armin76> rsalveti: link for it?
[18:29] <rsalveti> armin76: getting for you
[18:29] <ogra> so that looks like a delay
[18:29] <armin76> thanks
[18:29] <ogra> (for the freeze)
[18:29] <rsalveti> ogra: what you mean? we may need some bugfixing
[18:29] <rsalveti> but that's fine if we can do that tomorrow
[18:29] <ogra> rsalveti, i know ...
[18:29] <rsalveti> I believe
[18:29] <ogra> we wont have images tomorrow
[18:30] <rsalveti> ogra: didn't you say you fixed it?
[18:30] <ogra> unity will be uploaded tomorrow morning only
[18:30] <rsalveti> :-)
[18:30] <janimo> finally KDE packages are out of the FTBFS queue, now the chart looks familiar again
[18:30] <ogra> no,. janimo fixed it
[18:30] <janimo> although I wish Libo built on arm for a change
[18:30] <ogra> but the fix was sitting idle in upstreams bzr for three days
[18:30] <rsalveti> oh, will still be pushed...
[18:30] <ogra> it will be pushed
[18:30] <rsalveti> argh
[18:30] <ogra> but the desktop team just announced they wont make it before tomorrow morning
[18:31] <ogra> which means we will have no images tomorrow morning
[18:31] <rsalveti> yeah
[18:31] <ogra> with luck we'll have them in the evening
[18:31] <janimo> maybe I should have made a package upload as well. Dunno, I was trying not to mess with too many bzr branches at once
[18:31] <rsalveti> yeah
[18:31] <rsalveti> I thought you also did a package upload
[18:31] <janimo> no
[18:31] <ogra> janimo, given treh experience we now have with nux and unity slowness, i would actually recommed package fixes in the future
[18:31] <janimo> I saw they upload quite frequently
[18:32] <janimo> so I leave it to them
[18:32] <rsalveti> it's taking too much time for the fixes to be in the archive
[18:32] <ogra> nux took ages
[18:32] <rsalveti> yeah
[18:32] <ogra> because they kept back a new upstream relese until FF
[18:32] <janimo> true, but I did not know how long it takes them. I will consider package uploads from now on though
[18:32] <rsalveti> seems they don't care much about arm
[18:33] <ogra> given the silly casting errors that cause our build failures i would agree with that :)
[18:33] <rsalveti> if it's breaking our images, then a package upload would be better I guess
[18:33] <janimo> rsalveti, I can't blame them. The flood of bugmails I am getting since on the unity team has * a lot* of crash reports
[18:33] <janimo> they ned to make that stabl eon x86 before caring for arm
[18:33] <rsalveti> crash or ftbfs?
[18:33] <janimo> crashes
[18:33] <rsalveti> crash is fine :P
[18:33] <ogra> yeah
[18:33] <janimo> I still canoot run unity on my two x86 laptops I test on
[18:33] <rsalveti> ftbfs blocks images
[18:33] <janimo> just goes away
[18:33] <ogra> ftbfs is blocking
[18:34] <janimo> ogra, rsalveti I know, what I am saying they are swamped by bugfix work so probably let us handle arm and only do it when explicitly pinged
[18:34] <ogra> i'm really curious if unity-2d will run at all
[18:34] <ogra> janimo, right, do package fixes and additionally dup a merge request in place for next upstream
[18:35] <rsalveti> armin76: https://github.com/sebjan/linux-2.6/tree/int-2.6.38-rc6-iv3
[18:35] <ogra> *dump
[18:35] <rsalveti> yeah
[18:35] <rsalveti> otherwise we're not making a3
[18:40]  * armin76 wonders why is it hidden
[18:40] <armin76> rsalveti: thanks
[18:41] <rsalveti> armin76: it's not hidden, heavy dev
[18:41] <rsalveti> armin76: if you follow linaro tree you'll probably get the same patch set
[18:41] <Neko> arm guys!
[18:41] <Neko> I have a quandry
[18:41] <Neko> I want to install from ubuntu-standard a full gnome desktop
[18:42] <Neko> but ubuntu-desktop requires unity
[18:42] <Neko> and jockey-gtk
[18:42] <sebjan> rsalveti: actually, if you talk about my tag, it does not contain the Linaro patches, only TI ones on top of mainline kernel
[18:42] <Neko> but unity depends on compiz
[18:42] <Neko> and jockey-gtk depends on nvidia-common
[18:42] <Neko> *what* is going on?
[18:42] <Neko> (btw unity-2d doesn't provides: unity either)
[18:42] <rsalveti> sebjan: true, I mean, if he gets the andy linaro tree he'll get everything
[18:43] <sebjan> rsalveti: correct
[18:43] <rsalveti> as he's also merging your tree
[18:43] <ogra>  Neko unity is the default ubuntu-desktop in natty
[18:43] <rsalveti> Neko: we're fixing this
[18:43] <ogra> Neko, and unity-2d doesnt provide unity since it uses bits and pieces of unity
[18:44] <ogra> -2d needs unity installed
[18:44] <GrueMaster> Neko.  Packages are being rebuilt frm massive uploads last week.  Expect a little turbulence in the pool, it should settle by the end of the week.
[18:44] <Neko> right and I tried that but unity depends on compiz-abisomething
[18:44] <ogra> jockey is fixed since half a day
[18:44] <Neko> ah okay so I am just in the middle of an update?
[18:44] <Neko> phew..
[18:44] <rsalveti> yeah
[18:44] <GrueMaster> Yes.
[18:44] <ogra> the rest will be fixed tomorrow or so
[18:44] <Neko> okay I am satisfied then
[18:44] <rsalveti> Neko: we still don't have images
[18:44] <rsalveti> since feb 16th
[18:44] <ogra> depending how fast the desktop team works
[18:44] <rsalveti> we expect this to be fixed this week
[18:45] <Neko> will there be a way to install a maverick-ish gnome desktop without unity?
[18:45] <ogra> we're waiting too
[18:45] <ogra> not when using ubuntu-desktop
[18:45] <Neko> but there's no new meta package to be back to the old behavior?
[18:46] <janimo> ogra, I am not sure u-2d need unity installed
[18:46] <Neko> I dunno. I like the IDEA of unity, just not the way it soaks up all the screen space with it's little menu bar
[18:46] <janimo> what pieces it uses from it?
[18:46] <ogra> janimo, the dash, icons etc
[18:46] <janimo> I don't see those in the depends
[18:47] <ogra> and iirc it build deps on libunity
[18:47] <janimo> I think there is some common C++ helper indeed
[18:47] <ogra> which should add it to debs through shlibs
[18:47] <janimo> but not unity (the apps ) itself
[18:47] <ogra> the point is that you can install all bits and pieces independently
[18:47] <ogra> i.e. i used the panel on a normal gnome desktop for a while here ;(
[18:48] <ogra> err
[18:48] <ogra> ;)
[18:48] <ogra> the unity package should probably have more recommends though
[18:48] <ogra> err
[18:48] <ogra> unity-2d indeed
[18:51] <ogra> GrueMaster, if you have some spare cycles today it would be nice to know if unity-2d still runs ... nowing that in advance before we have images would be helpful
[18:52] <GrueMaster> I'm already downloading the updates now.
[18:52]  * ogra hugs GrueMaster 
[18:55] <Neko> I'm kind of impressed with how fast natty is just as a running system... I hacked in gnome and ambience theme and the backdrops and it's like lightning
[18:56] <Neko> unity seems to run okay it's just I had to spend 2 hours getting it to even install
[18:56] <Neko> but I understand, we had this problem during Maverick... trying to do work during the day before and the day after an alpha release = eek :D
[18:58] <GrueMaster> Neko, when booting, you can select classic desktop when logging in.  not sure if there are plans for a meta package.
[18:58] <Neko> it's no problem
[18:59] <Neko> it just scared me that I couldn't install ubuntu-desktop because it depends on unity and unity didn't work
[18:59] <Neko> which means no desktop ata ll
[18:59] <Neko> at all
[18:59] <Neko> I'll try it again mid-March and it will hopefully Just Work (tm) :)
[18:59] <ogra> you should try on thu.
[19:00] <Neko> release day? I doubt I will have good luck then :D
[19:00] <ogra> ??
[19:00] <Neko> we usually have frightening problems with bandwdith to the ubuntu servers
[19:00] <ogra> this thursday
[19:00] <Neko> Alpha 3 release date is Thursday
[19:00] <ogra> yes
[19:00] <Neko> hundreds of geeks downloading new ISOs, pulling packages for their alpha 2 systems...
[19:00] <ogra> that shouldnt affext ports.ubuntu.com though
[19:01] <Neko> in theory :D
[19:02] <GrueMaster> Neko: I have my own mirror of ports so I don't get hit by bandwidth issues.
[19:03] <Neko> I use approx so I have a good buffer but it doesn't help when 90% of stuff got rebuilt
[19:03] <GrueMaster> my mirror updates every 4 hours.  real slow for the first few weeks after UDS, but good overall.
[19:32] <ericb2> janimo: ping ?
[19:36] <janimo> ericb2, hello
[19:37] <ericb2> janimo: hi. Are you Jani Monoses ?
[19:37] <janimo> ericb2, yes
[19:37] <ericb2> janimo: maybe you'll be interested : I implemente the interlock part in arm assembler for armv7 +  in OOo4Kids
[19:38] <janimo> ericb2, regarding the recent bug I filed?
[19:38] <ericb2> janimo: in sal/osl/unx/interlck.c
[19:38] <ericb2> janimo: I'm not aware
[19:38] <janimo> I was under the impression we need to move away from asm
[19:38] <janimo> I sent a patch to libo to use gcc atomic builtins for that
[19:39] <ericb2> janimo: it woarks really wel on OOo4Kids
[19:39] <janimo> I think gcc does a good job for atomic ops nowadays
[19:39] <janimo> and imo the less ifdefs and assembly code the better :)
[19:39] <ericb2> janimo: looks like I did the same
[19:39] <janimo> ericb2, is that of fork of OO?
[19:39] <ericb2> janimo:  http://eric.bachard.free.fr/patches/OOo4Kids/linux_arm/arm_DEV300_m93.diff
[19:40] <ericb2> janimo: yes, OOo4Kids (and OOoLight ) is a fork of OOo
[19:40] <ericb2> janimo: only the atomic part might interest you
[19:40] <janimo> ah I see, so you created the original arm optimization patch for OO?
[19:40] <janimo> that is currently in natty
[19:40] <ericb2> janimo: I wrote this patch, but I don't know what other people dd with it :)
[19:41] <ericb2> janimo: on my BeagleBoard, the change is really visible
[19:41] <ericb2> janimo: and faster
[19:41] <ericb2> janimo: so far, no crash yet, but maybe the patch needs to be tested intensively
[19:42] <janimo> ericb2, it is a coincidence then, as I only filed a bug related to this against ubuntu libo today
[19:43] <janimo> I bet it is faster, the alternative used pthread mutexes
[19:43] <ericb2> janimo: yes. Some people like rene cry because I don't care armv6 or prior
[19:43] <janimo> still I think you'd get the same improvement and much cleaner code - no configure foo and no inline asm, using only the bits you used for arm <7 in your code
[19:43] <ericb2> janimo: what is the problem
[19:44] <ericb2> janimo: I tested both, and the inline asm is faster
[19:44] <janimo> ericb2, well you care for that too, by letting gcc do the right thing there
[19:44] <ericb2> janimo: since I added other fixes
[19:44] <janimo> I did not perf test but looking at the code generated by gcc I see the same sequence of instructions so I was hopiong the performance is more or less the same
[19:44] <ericb2> janimo: and the build is fine on Debian, on Ubuntu and on OE distributions (e.g. the one sakoman provides)
[19:45] <janimo> one fix needed is meory barriers
[19:45] <janimo> on beagle there is no need
[19:45] <janimo> but on SMP systems like the panda not using dmb can lead to bugs I guess
[19:46] <janimo> ericb2, https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/726529
[19:46] <ubot2> Launchpad bug 726529 in libreoffice "use arm assembly bits only for gcc < 4.6 on ARM > 6" [Undecided,In progress]
[19:46] <ericb2> janimo: you're probably right. I filed the code thinking people could be interested, and nobody can imagine all cases
[19:46] <ericb2> janimo: so any improvement is good to hear
[19:47] <janimo> ericb2, I think they were interested as long as your patch is part of the current LibO and former OO builds in Ubuntu
[19:47]  * ericb2 discovering the patch is part of current Libo 
[19:47] <janimo> LibO in Ubuntu
[19:47] <janimo> it is a patch Ubuntu carries
[19:47] <ericb2> janimo: I know
[19:47] <janimo> but it was commited to LibO as well today
[19:47] <janimo> as it makes sense for older gcc build
[19:48] <ericb2> janimo: I was not aware. I don't follow Libo
[19:48] <ericb2> janimo: when Libo was decided, I was even not invited. Now, they can die
[19:48] <janimo> it was mentioned in the bugs filed.
[19:48] <ericb2> janimo: no problem
[19:48] <janimo> ericb2, I am not sure it was invitation based. I do not know the details
[19:49] <janimo> I am sure they have a better future than OO, it is a shame you parted ways
[19:49] <ericb2> janimo: well, I think I contribute since a long while to OOo, and not inform me was a choice. No problem for me anyway
[19:49] <janimo> they are responsive, I doubt you'll get your ARM patches in OO
[19:49] <janimo> ericb2, I am not sure every contributor was made aware of the fork before the announcement
[19:50] <janimo> if so it must have been an oversight in your case
[19:50] <ericb2> janimo: it was thought : use it if you consider it usefull. If not well that's no problem
[19:50] <ericb2> janimo: no, I was very close to people organising everything, and not inform me was a choice
[19:50] <janimo> I only got involved (slightly) since the fork and they come across as the most friendly project I have seen in a while
[19:51] <janimo> ericb2, sorry to hear that. HAve you asked them afterwads, did they clarify anything?
[19:51] <janimo> ericb2, is this ARM patch originally authored by you?
[19:51] <ericb2> janimo: I wrote it, yes
[19:51] <ericb2> janimo: but I didn't follow the story
[19:52] <ericb2> janimo: precisely, I wrote the one I provided you the link http://eric.bachard.free.fr/patches/OOo4Kids/linux_arm/arm_DEV300_m93.diff
[19:52] <janimo> hmm, sadly there is no attribution on the patch in Ubuntu
[19:52] <janimo> the one in ubuntu looks very similar
[19:52] <ericb2> janimo: as you can see, I backported it to OOo, making it more simpler for other forks,  people
[19:52] <ericb2> janimo: who commited it ?
[19:53] <ericb2> janimo: http://cia.vc/stats/project/OOo4Kids
[19:53] <ericb2> janimo: revision r1152
[19:53] <janimo> today it was Bjoern, the UBuntu Libo maintainer. It was part of the ubuntu tree for a long time so he probably did not know whom to attribute
[19:54] <ericb2> janimo: svn diff -cr1152 svn://svn.adullact.net/svnroot/ooo4kids1/trunk
[19:54] <janimo> what other changes does OO4kids have in general?
[19:54] <ericb2> janimo: no Java, OOo - 40%
[19:54] <ericb2> janimo: no Basic, just Python works
[19:54] <janimo> this 1152 commit is a few weeks old, is the patch older?
[19:54] <ericb2> janimo: and new UI, working with students
[19:56] <ericb2> janimo: the commit is the first time I published my code. After, I backported to DEV300_m93, and I uploaded the patch I shown you
[19:56] <ericb2> janimo: other patch, is attached to OOo issue zilla
[19:56] <ericb2> janimo: let me retrieve the link
[19:56] <janimo> ericb2, ok, for some reason I was under the impression the patch in Ubuntu is older, but I do not follow Ubuntu OO, it was just a coincidence I spotted this yesteday
[19:56] <ericb2> janimo: http://www.openoffice.org/issues/show_bug.cgi?id=117017
[19:57] <ubot2> ericb2: Error: Could not parse XML returned by OpenOffice.org: timed out (http://openoffice.org/issues/xml.cgi?id=117017)
[19:57] <ericb2> janimo: I really wrote it
[19:57] <ericb2> janimo: I learned everything, and spent several nights to that
[19:58] <ericb2> janimo: and I ignored there was one similar patch on Ubuntu repo
[19:58] <ericb2> janimo: do you have the link ?
[19:58]  * ericb2 curious
[19:59] <janimo> checking
[19:59] <janimo> this went into LibO today http://cgit.freedesktop.org/libreoffice/ure/commit/?id=83f2c071758ae7d74669d992e272e50057b895ed
[20:00] <janimo> I am not sure there's a plain Ubuntu patch except in a tgz somewhere
[20:02] <ericb2> janimo: the patch I attached to IZ and I commited is dated 19 february. I'm pretty sure I completed it one day before. This leads to 18 february. Here is the story I know
[20:02] <ericb2> janimo: what happens with gcc >= 4.6 ?
[20:04] <janimo> ericb2, it generated good enough code that it does not need to be manually written
[20:04] <janimo> I mean for the _sync_XXX stuff
[20:04] <ericb2> janimo: __sync_add_and_fecth, ___sync_sub_and_fetch and al ?
[20:05] <janimo> yes
[20:05] <ericb2> janimo: I see
[20:05] <janimo> that was part of your patch as well right?
[20:05] <ericb2> janimo: yes. Ben ( a guy building on qemu + Debian arm ), had an issue with that. Was my fault
[20:05] <ericb2> janimo: and I discoverd the stuff
[20:06] <ericb2> janimo: more precisely, he had an undefined  __sync_add_and_fetch_4  or something
[20:06] <ericb2> janimo: and after some grep's I discovered the thing, and had the idea to learn arm asm :)
[20:07] <ericb2> janimo: some years ago, I worked on m68k asm , and a bit on x86 asm too
[20:07] <ericb2> so was not much surprised
[20:08] <ericb2> janimo:  as I mentionned in the log, Simon Guinot, helped me (he explained me the change after armv5
[20:08] <ericb2> )
[20:09] <ericb2> janimo: e.g. swap  vs  ldrex strex
[20:09] <janimo> right
[20:10] <ericb2> janimo: I'm about to propose a subject for GSoC, about performance issues on arm
[20:10] <janimo> ericb2, hmm so that arm patch went into debian via Rene?I see it in the debian pkg changelog
[20:10] <ericb2> janimo: OOo4Kids is an elephant, and we can improve a lot
[20:10] <ericb2> janimo: probably
[20:10] <janimo> ericb2, I know OO is an elephant but I think much better gains could be had by doing higher level optimizations
[20:10] <ericb2> janimo: rene was crying a lot after me
[20:10] <janimo> before going low level
[20:10] <ericb2> janimo: he didn't read correctly the issue and he was red :)
[20:10] <janimo> like doing much less disk IO
[20:11] <ericb2> janimo: yes
[20:11] <janimo> and pruning code and duplication and 20 year iolkd cruft
[20:11] <ericb2> janimo: and remove lot of useless stuff
[20:11] <ericb2> janimo: and more if affinity ^^
[20:11] <janimo> at this point I think the code needs cleanup much more that asm level magic that only a ahdnful of devs understand well
[20:12] <ericb2> just time is missing me : I got a real life, a real job, a family, doing a lot of sport :)
[20:12] <ericb2> janimo: I'm in OOo code since 2004, and I worked a lot on the native Mac OS X port
[20:12] <ericb2> janimo: including the MAc Intel one (we had to dive into the bridge too)
[20:13] <doko_> ericb2: this is what Sweetshark did commit. http://libreoffice.pastebin.com/etTyZc5R   GCC-4.6 inlines the _sync_* primitives
[20:13] <ericb2> doko_: probably
[20:13] <ericb2> doko_: as I told, I didnt follow what happened since I donated the patch
[20:22] <ericb2> doko_: that's true I'd have appreciated to see my name mentionned somewhere though ...
[20:23] <doko_> ericb2: I didn't see any name within the patch, nor do I know where it was submitted ...
[20:24] <ericb2> doko_: it was originaly submitted to OOo IZ, to simplify the backports for all forks and so on.
[20:25] <ericb2> doko_: imagine it was submitted to LO, it would never have been reversed to OOo. So to respect everybody, the most simple was to attach it to OOo IZ
[20:25] <doko_> ericb2: please tell Sweetshark on #ubuntu-desktop
[20:48] <desrt> ogra: word up
[20:48] <ogra> hohoho
[20:49] <desrt> do you have any idea if we'll be getting alternate toolchains for arm?
[20:49] <desrt> particularly: non-eabi and softfloat variants?
[20:49] <ogra> alternate ? like LLVM ?
[20:49] <ogra> ah
[20:49] <desrt> not really important for the compiler and binutils as much as for the libgcc...
[20:49] <ogra> not in natty
[20:49] <desrt> this stuff is important for building u-boot :)
[20:50] <ogra> we will get a hardfloat port in natty+1 which will run in parallel with the current one
[20:50] <ogra> what for are you building u-boot ?
[20:50] <desrt> the kobo
[20:50] <desrt> i love this device
[20:50] <desrt> it's cheap and hell and quite awesome
[20:50] <ericb2> ogra: is hard float reliable ?
[20:50] <ogra> nice
[20:51] <desrt> it has a somewhat hacked up firmware installed
[20:51] <ogra> ericb2, according to markos_ who does the port in debian currently, it is, yeah
[20:51] <desrt> they released the code as a bunch of tarballs against old linux/redboot releases
[20:51] <desrt> and the patches are quite awful
[20:51] <ogra> what architecture is that ?
[20:51] <desrt> i've managed to get u-boot going on it and also have some patches against the kernel to make that work
[20:51] <ericb2> ogra: starting which proc ?
[20:52] <ericb2> ogra: for omap3 one told me it was not really. But maybe more recent is safe
[20:52] <ogra> angstrom is fully built in hardfloat mode afaik
[20:52] <ogra> since quite a while
[20:52] <ericb2> ogra: interesting
[20:55] <markos_> ericb2, it depends on what you mean by reliable, usually packages just work, but there are a few who need special attention :)
[20:55] <markos_> these are just a few though
[20:56] <markos_> debian has reached 87% and we're hoping we can reach 95% soon
[20:56] <ericb2> markos_: what can bring hardfloat exactly ?
[20:56] <markos_> er, a hardfloat abi?
[20:57] <ericb2> markos_: yes, I know, but in the real life:  is it that faster ?
[20:57]  * desrt thought that the change to eabi brought hardfloat with it
[20:57] <ericb2> markos_: just a question, because I didn't test yet
[20:57] <markos_> it depends on what apps you depend on
[20:57] <markos_> most apps benefit 5-30% depending on their use of fp
[20:58] <markos_> some don't benefit at all, while apps heavy on fp might be 200% faster (like a raytracer, like pov, yes it was actually 200% faster)
[20:58] <ericb2> markos_: the one I have in mind is OOo4Kids (an OOo fork)
[20:59] <ericb2> markos_: I'm working on performances issues, and am interested by everything who cold help in this domain
[21:00] <markos_> no idea how much better -if at all- OOo would be, though from my experience, anything that renders fonts is faster, ~20-25%
[21:00] <markos_> but ymmv with OOo
[21:01] <ericb2> markos_: so it is interesting
[21:01] <markos_> yes it is, that's what I've been trying to tell people all along :)
[21:03] <ericb2> markos_: do yo have a link, where I could read the flags being used, the cases .. and so on ?
[21:04] <ogra> you need the whole distro being built for hardfloat
[21:04] <ogra> the binaries wont run on a softfloat distro
[21:04] <markos_> ericb2, working on getting armhf d-i these days
[21:04] <ericb2> ogra: isn't there a flag allowing both ?
[21:05] <ericb2> markos_: great :)
[21:05] <markos_> ogra, well he coud use a chroot
[21:05] <ogra> they are binary incompatible
[21:05] <ogra> yeah. you could use a chroot
[21:05] <ogra> or a vm
[21:05] <ericb2> markos_: I'm not a specialist (arm is a jungle), but extremely curious and interested
[21:05] <ogra> both would work
[21:06] <markos_> ericb2, give me a few weeks, I've commited some armhf stuff to d-i, but there remain a few irritating points still to fix
[21:06] <markos_> anyway gotta go, have to tell a bedtime story :)
[21:06] <ericb2> markos_: I will. thanks :)
[21:06] <ogra> ubuntu will have it with the next release
[21:06] <ericb2> markos_: see you later
[21:06] <ogra> and slowly migrating 100% to it
[21:07] <ericb2> ogra: in fact, I'd like to provide an adapted version of OOo4Kids (or OOoLight)  for Ubuntu users
[21:07] <ogra> so watch this place ;)
[21:07] <ericb2> ogra: so I'll add what is mandatory, and stick your needs
[21:08] <ogra> if you could get it running with debian hf, you will also get it running in trhe upcoming ubuntu port
[21:08] <ericb2> ogra: currently, I got OOo4Kids building and working on natty
[21:08] <ericb2> ogra:  but I used soft fp
[21:09] <ogra> right, thats fine for natty
[21:09] <ericb2> ogra: ok
[21:09] <ogra> n+1 will have both
[21:09] <ogra> soft and hard
[21:09] <ericb2> ogra: the only thing I'll need is a new micro SD card: and I'll install any experimental version on it
[21:52] <Sweetshark> ericb2: ping?