[00:34] <micahg> chrisccoulson: any chance you can upload edbrowse?
[09:10] <BUGabundo> m0rning
[10:26] <chrisccoulson> asac - ok, xulrunner is good to go. i can tag that for release when you are ready
[11:24] <asac> chrisccoulson: i am ready ... i trust you ;)
[11:24] <chrisccoulson> asac - ok, i will tag that now
[11:24] <chrisccoulson> thanks
[11:24] <chrisccoulson> are you ok to do an ubufox upload today?
[11:25] <asac> chrisccoulson: we can surely do a rc2 today ;)
[11:25] <asac> i didnt fix one issue
[11:25] <asac> but that has to come monday ;)
[11:25] <asac> the "get ubuntu extension" link is missing in addons dialog
[11:25] <chrisccoulson> asac - excellent, thanks. i think rick is quite keen to switch search providers before the weekend
[11:25] <asac> chrisccoulson: sure. that will be done
[11:27] <asac> chrisccoulson: did you try if the lockPref thing helps?
[11:27] <asac> i remember we also had another location added, but i think just that should be ok
[11:27] <chrisccoulson> asac - ok, that's tagged now. i'm uploading the tarball to http://people.canonical.com/~chrisccoulson but that may take another 5 minutes or so
[11:28] <chrisccoulson> i've not tried the lockPref patch yet, i was going to do a build this morning and test that
[11:28] <asac> chrisccoulson: the tarball is a new one?
[11:28] <asac> ok
[11:28] <asac> give it to me ... or is that in some ppa already?
[11:28] <chrisccoulson> yeah, it's for the 3.6.3 release
[11:29] <asac> chrisccoulson: oh
[11:29] <asac> chrisccoulson: we usually add - see USN-XXX too
[11:29] <chrisccoulson> i'll have a look to see if it's in a PPA, but my connection is now going super slow, as i'm using all my uplink ;)
[11:29] <asac> e.g. basically the same heading you have in stable updates
[11:29] <asac> +'the packaging changes
[11:29] <chrisccoulson> ah, ok. i'm not sure that i did that for the FF upload :-/
[11:30] <chrisccoulson> i did it for all the stable updates though
[11:30] <asac> well. next time. this thing you can uncommit ;)
[11:30] <asac> assuming you did the release commit in the last few minutes
[11:31] <asac> chrisccoulson: wanna do that still?
[11:31] <chrisccoulson> do we have a USN for that already? i don't think i've got one
[11:31] <asac> ok upload seems to be still going
[11:31] <asac> chrisccoulson: you dont? didnt we update xul in stable releases?
[11:31] <asac> hmm
[11:31] <asac> chrisccoulson: you are right ;)
[11:31] <asac> 1.9.2 isnt tracked yet
[11:31] <asac> sorry for the noise ;)
[11:32] <chrisccoulson> heh, that's ok :)
[11:32] <asac> ist just that often we release to dev release what goes to unstable. there we add the USN
[11:32] <asac> ;)
[11:32] <asac> so next upload would have that
[11:32] <chrisccoulson> yeah, i'll remember that
[11:32] <asac> assuming it goes everywhere
[11:32] <chrisccoulson> i probably would have forgotten that anyway
[11:32] <chrisccoulson> so, i'll make sure i do that next time
[11:33] <asac> chrisccoulson: did you check the gre-version etc. in the source tarball?
[11:33] <asac> e.g. if its a real tagged checkout?
[11:36] <chrisccoulson> asac - is that defined in config/milestone.txt? (that says 1.9.2.3 in there)
[11:36] <chrisccoulson> i did the checkout myself anyway...
[11:36] <asac> yes
[11:36] <asac> right
[11:36] <asac> chrisccoulson: you didnt use mozclient?
[11:37] <asac> e.g. ./debian/rules get-orig-source DEBIAN_TAG ... ?
[11:37] <chrisccoulson> yeah, that's how i did it
[11:37] <asac> kk
[11:37] <chrisccoulson> cool, the tarball is copied across now
[11:37] <asac> chrisccoulson: upload finished?
[11:37] <asac> kk
[11:37] <chrisccoulson> i need a faster uplink :)
[11:37] <asac> chrisccoulson: have a signature?
[11:38]  * asac paranoia ;)
[11:39] <chrisccoulson> asac - the changes file has that in doesn't it?
[11:40] <asac> chrisccoulson: it has that if you upload .dsc etc.
[11:40] <chrisccoulson> asac - the md5sum in the changes file is fe5d931b486569208ed400970cc796ab
[11:41] <asac> kk i think thats good enough
[11:41] <asac> not saying that this is a good channel to exchange such things ;)
[11:42] <chrisccoulson> excellent, xchat just crashed
[11:43] <asac> sure the md5sum comes from you?
[11:43] <asac> or are you still you?
[11:43] <asac> ;)
[11:43] <asac> chrisccoulson: do you have your signed changes ;)?
[11:43] <asac> nevermind
[11:45] <chrisccoulson> asac - ok, i uploaded the whole source package there now (including the signed changes)
[11:57] <asac> chrisccoulson: did you drop the search code from firefox yet?
[11:57] <asac> or did i do that already=?
[11:57] <asac> debian/firefox.js
[11:57] <chrisccoulson> asac - i've done that in bzr already (dropped the yahoo code and added the google ones)
[11:58] <chrisccoulson> i just need to upload that today too
[11:58] <asac> let me see
[11:59] <asac> chrisccoulson: what about the ie, params?
[12:00] <chrisccoulson> do we have to keep those? i updated it to match the URL's we were sent
[12:00] <asac> not sure
[12:00] <asac> they probably are there for a reason ;)
[12:02] <chrisccoulson> asac - "Optional. The ie parameter sets the character encoding scheme that should be used to interpret the query string. The default ie value is latin1."
[12:02] <chrisccoulson> (from http://www.google.com/cse/docs/resultsxml.html)
[12:03] <asac> chrisccoulson: i think we should keep iutf-8 then
[12:03] <asac> by default
[12:04] <chrisccoulson> ok, i can do that
[12:10] <asac> xul is slowly uploading
[12:10] <asac> my uplink is in  bad mood today ;) ... guess needs a reset of modem or so
[12:11] <chrisccoulson> what speed uplink do you have?
[12:11] <chrisccoulson> i've added the character encoding parameters back to the search URL in bzr now
[12:12] <chrisccoulson> i'm going to do a test build of firefox shortly, and then will get that uploaded too once i've checked everything is working
[12:16] <chrisccoulson> asac - can you recreate bug 557640?
[12:16] <chrisccoulson> i just tried it but it works fine here
[12:17] <asac> chrisccoulson: i think we dont have networkmanager integration
[12:17] <asac> that makes folks not seeing the offline page
[12:17] <asac> switch to offline and go to home
[12:17] <asac> tp see what they want
[12:18] <asac> i think we had networkmanager enabled in the past
[12:18] <asac> toolkit.networkmanager.disable
[12:18] <chrisccoulson> yeah, i just tried that. but i also tried opening firefox with my network off, and i saw the page i expected too
[12:18] <asac> also our offline page mechanism doesnt send a real ping to the world
[12:18] <asac> anymore
[12:18] <asac> so we rely on offline
[12:18] <asac> chrisccoulson: it might hav been in cache
[12:18] <asac> check the offline page
[12:18] <chrisccoulson> heh
[12:19] <asac> so you see its a different one (most likely)
[12:19] <chrisccoulson> yeah, that might be it ;)
[12:19] <asac> https://edge.launchpad.net/ubuntu/+source/xulrunner-1.9.2/1.9.2.3+nobinonly-0ubuntu1
[12:19] <chrisccoulson> one second, will try that again
[12:19] <chrisccoulson> asac - thanks
[12:24] <chrisccoulson> asac - is it enough just to change the value of toolkit.networkmanager.disable to false, or does it need something else to fix?
[12:24] <chrisccoulson> (i could recreate it with a fresh profile btw, so it was just cached) ;)
[12:25] <chrisccoulson> i tried changing the value here, and firefox seems to correctly switch to offline mode when i disable the network
[12:27] <asac> chrisccoulson: i think we had that in firefox.js at some point
[12:27] <chrisccoulson> asac - ok, i can add that back then if you think it's reasonably safe
[12:27] <chrisccoulson> (its not in firefox.js any more)
[12:31] <BUGabundo> see you all on Sunday!!
[12:31] <BUGabundo> bye
[12:31] <asac> good bye BUGabundo
[12:31] <BUGabundo> TRYYYYPPPPPPPPPPPINNNNNNNNNNNNNNNNNGGGGG
[12:31] <BUGabundo> :)
[13:03]  * asac lunch
[13:08] <ripps> fta2: youtube html5 is working now, did you fix the build system?
[13:08] <fta2> ripps, yep
[13:09] <fta2> but i'm not sure my 1st tweak is required. the 2nd sure is but i want to try without the 1st one
[13:09] <ripps> thanks for keeping with it, now I can switch back to using chromium
[13:11] <fta2> ripps, if i give you a deb with just the 2nd fix, are you willing to try it?
[13:12] <ripps> fta2: what do mean? seperate package with no sse2?
[13:26] <LLStarks> wait
[13:27] <LLStarks> html5 video on youtube now works with the fox?
[13:27] <ripps> LLStarks: no chromium
[13:27] <LLStarks> oah
[13:28] <ripps> those with cpus that didn't have sse2 crashed
[13:28] <LLStarks> i see lorentz beta came out today, is there a ppa of it?
[13:28] <LLStarks> that's odd
[13:30] <chrisccoulson> asac - ok, the network manager integration is not working that reliably anyway. when you turn off the networking, the browser goes in to offline mode, but browser.offline is not updated
[13:30] <chrisccoulson> so, it still tries to load the online home-page :(
[13:31] <chrisccoulson> asac - ok, the network manager integration is not working that reliably anyway. when you turn off the networking, the browser goes in to offline mode, but browser.offline is not updated
[13:31] <chrisccoulson> so, it still tries to load the online home-page :(
[13:32] <chrisccoulson> (i hope i didn't send that twice. i think i tried to send it whilst i still had no network)
[13:34] <asac> what a pity
[13:34] <asac> bug :(
[13:34] <LLStarks> asac, any luck on getting bug 438868 elevated to papercut?
[13:35] <chrisccoulson> i'm not sure that's a firefox issue
[13:35] <chrisccoulson> my gf keeps bugging me about that too
[13:44] <fta2> ripps, no. i have two workarounds: 1/ no ssse3/rint and 2/ no sse2. in the ppa, you now have both, but i think only the 2nd one is needed, so either i try without the 1st one, or i keep both
[13:45] <ripps> fta2: go ahead, I'll tell you if I get a crash
[13:52] <fta2> ripps, pushed to the ppa, give it some time to build.  thanks
[13:52] <fta2> i need to run now
[13:53] <ripps> fta2: is this for just the codecs or for the browser as well?
[13:53] <ripps> ...
[13:57] <chrisccoulson> asac - ok, it doesn't look like that's meant to work like we expect anyway (browser.offline is only set in browser/base/content/browser.js when toggling the checkbox in the menu)
[13:58] <chrisccoulson> so, we could probably fix that in ubufox if i can figure out a more reliable way of checking the network status
[14:11] <chrisccoulson> asac - ok, i fixed it in ubufox :)
[14:14] <asac> chrisccoulson: what diff?
[14:15] <chrisccoulson> asac - http://paste.ubuntu.com/411608/
[14:15] <asac> good
[14:15] <chrisccoulson> asac - ok, i'll get that pushed to bzr in a second
[14:17] <asac> chrisccoulson: err
[14:17] <asac> chrisccoulson: i committed it to upstream branch
[14:17] <asac> asac@tinya:~/Development/upstream/asac/ubufox.main$ bzr commit -m "* fix online/offline detection by using nsIIOService rather than browser.offline pref
[14:18] <asac> >   - thx to Chris Coulson <chrisccoulson@ubuntu.com> for the patch"
[14:18] <asac> Committing to: bzr+ssh://asac@bazaar.launchpad.net/~asac/ubufox/main/
[14:18] <asac> modified components/aboutHome.js
[14:18] <asac> Committed revision 211.
[14:18] <asac> please test lp:ubufox if all is fine
[14:18] <asac> want to do the rc2 release
[14:18] <chrisccoulson> asac - thanks
[14:18] <chrisccoulson> i'll pull it again and re-test it
[14:22] <chrisccoulson> asac - ok, that's looking good
[14:32] <asac> chrisccoulson: uploaded etc.
[14:32] <chrisccoulson> asac - excellent, thanks
[14:33] <asac>   Uploading ubufox_0.9~rc2-0ubuntu1_source.changes: done.
[14:33] <asac> Successfully uploaded packages.
[14:58] <fta> ripps, the 32bit codecs are ready
[15:01] <LLStarks> fta, asac, are there any lorentz builds? i know the tarball is up, but i'd like to test how it interacts on a system level.
[15:02] <LLStarks> also, more fundamentally, is lorentz pegged for lucid or lucid-updates?
[15:03] <asac> LLStarks: -updates from what we see now
[15:04] <LLStarks> gotcha
[15:19] <asac> jdstrand: can you bin NEW desktop-webmail ;)
[15:19] <asac> ?
[15:30] <jdstrand> asac: done
[15:30] <asac> GREAT ;)
[15:31] <jdstrand> asac: is that to be launched from firefox (and therefore needs an apparmor profile addition?)
[15:31] <asac> jdstrand: no ... other apps run that
[15:31] <jdstrand> k
[15:31] <asac> jdstrand: this opens the browser
[15:31] <asac> with a special url
[15:31] <asac> so the other way around
[15:31] <jdstrand> ah, I see
[15:31] <jdstrand> cool
[16:03] <micahg> chrisccoulson: is it safe for me to bump the changelog to 3.6.4 for firefox to fix the dailies now?
[16:03] <chrisccoulson> micahg - it is now
[16:03] <chrisccoulson> eerrrr
[16:03] <chrisccoulson> actually, do we think there will be any more uploads before 3.6.3?
[16:04] <chrisccoulson> sorry, i meant 3.6.4
[16:04] <chrisccoulson> d'oh
[16:04] <chrisccoulson> i haven't got anything else that needs doing, but i'm not sure if anybody else hs
[16:04] <micahg> chrisccoulson: idk, but I think maybe we could branch .lucid if we need too
[16:04] <micahg> can we fix startup notifications on the next release?
[16:04] <micahg> I mean after release, teh patch is landed in 3.6.4
[16:05] <micahg> bug 469752
[16:05] <chrisccoulson> yeah, it might be a good time. i don't have any more release targetted bugs for firefox (except for the startup notification bug, but i will wait for 3.6.4 for that)
[16:05] <chrisccoulson> so, i don't have any plans to do another 3.6.3 upload
[16:06] <micahg> chrisccoulson: asac wants to get early adoption of 3.6.4 anyways, so we'll be pushing to security PPA next week when it hits the beta channels
[16:06] <chrisccoulson> yeah, that's fine
[16:06] <micahg> chrisccoulson: it contains OOPP for 3.6 branch
[16:07] <chrisccoulson> excellent :)
[16:07] <chrisccoulson> i wonder how much will break? ;)
[16:08] <chrisccoulson> that's going to need some serious testing effort
[16:09] <micahg> chrisccoulson: yes, but luckily, since we have in source xul, there should be less problems for firefox, but potentially more for the other xul based apps :-/
[16:09] <micahg> chrisccoulson: upstream's working to fix the remaining xul issues with OOPP before release though
[16:10] <micahg> chrisccoulson: if you have a minute, can you upload edbrowse :)
[16:18] <chrisccoulson> micahg - yeah, sorry, i forgot about edbrowse
[16:19] <chrisccoulson> ok, i'm just grabbing a drink and then i will do that
[16:19] <micahg> chrisccoulson: no worries, I'd just like to get a little testing from the users before final freeze :)
[16:19] <chrisccoulson> yeah, that would be good ;)
[16:20] <chrisccoulson> although, being a universe app there is still some scope for uploading at the start of the freeze (not that i would encourage that anyway)
[16:20] <chrisccoulson> but, it's easier to get stuff approved in universe rather than main
[16:20] <chrisccoulson> i'll get that done in a few minutes anyway
[16:39] <asac> bug 542662
[16:43] <micahg> asac: do you have time to package pyxpcom?
[16:50] <asac> no ;)
[16:50] <asac> i dont hav etime by definition :)
[16:51] <asac> feel free to package it ... but be sure that its maintainable across major version upgrades
[16:51] <micahg> asac: fun, well, I guess we'll see just how many things I can do this weekend :)
[16:51] <asac> micahg: dont do that for lucid
[16:51] <asac> its too late
[16:51] <asac> nothing goes in that wasnt planned yet
[16:51] <micahg> asac: some apps need python-xpcom
[16:52] <micahg> asac: which was dropped from xul191 and xul192
[16:52] <micahg> asac: virtualbox specifically
[16:52] <asac> where is the virtualbox bug?
[16:53] <asac> imo it should be possible to ship tha twithout pyxpcom
[16:53] <asac> everything that uses pyxpcom now needs to get removed imo
[16:53] <micahg> asac: https://bugs.edge.launchpad.net/ubuntu/+bug/480407/comments/5
[16:53] <asac> virtualbox is still in archive ;)
[16:55] <micahg> asac: oh, maybe the user was mistaken then...
[16:55]  * micahg doesn't see anything that needs it
[16:56] <micahg> and I still need to chat with upstream about it, so I'm going to de-milestone it then
[16:56] <asac> thanks
[16:56] <asac> if virtual box needs it, server team should escalate that bug
[16:57] <micahg> I'll add a note in my comment too that if there's anything critical relying on it, to speak up now
[17:01] <micahg> chrisccoulson: that's why you couldn't see my sponsor bugs ;)
[17:01] <chrisccoulson> micahg - we don't get notified of them anyway ;)
[17:28] <cwillu_at_work> when building firefox via "apt-get source; ...; fakeroot debian/rules binary", is it sufficient to just dump a patch into debian/patches + append the patch name into debian/patches/series + fakeroot debian/rules binary?
[17:29] <cwillu_at_work> or do I need to touch something to ensure that the patch is applied?
[17:46]  * cwillu_at_work starts bouncing
[18:04]  * cwillu_at_work heads off, but will read the scrollback
[18:34] <asac> cwillu_at_work: we use quilt
[18:34] <asac> cwillu_at_work: you dump patch in patches
[18:34] <asac> and add it to debian/patches/series
[18:34] <asac> then build
[18:56] <fta> ripps, did you try the last build?
[18:56] <ripps> fta: yep, worked perfectly :)
[18:56] <ripps> Although, I'm not going to keep up2date with the daily ppa, I'm going back to dev ppa.
[18:58] <fta> ripps, sure, you can use -dev or lucid (same as -beta)
[18:58] <fta> i will update the codecs everywhere
[18:58] <ripps> great
[18:59] <fta> ripps, so you said -extra ~ucd3 is fine for you now, right?
[19:00] <ripps> fta: yes
[19:01] <ripps> I think it actually looks better than google-chrome's html5. Their's was more grainy/pixelated
[19:06]  * ripps watches some muppets youtube videos
[19:09] <micahg> asac: please check response on bug 480407 and let me know if it needs to be done, I'll fit it in somehow if yes
[20:12] <fta> weird, liferea is no longer auto-updating my feeds, i have to manually ask for updates
[20:12] <fta> kenvandine, ^^
[20:12] <kenvandine> no idea, i haven't used liferea in years
[20:13] <kenvandine> recent upload?
[20:15] <fta> not sure, started a few days ago
[20:19] <fta> why do we have an old acroread in the partner repo??
[20:19] <fta> 9.1.0-7jaunty2 in lucid :(
[20:19] <fta> upstream ships 9.3.2
[20:20] <micahg> fta: partner forgot?
[20:21] <fta> no update in a year
[20:21] <micahg> fta: there are probably 2 dozen CVEs for it
[20:22] <fta> indeed
[20:45] <fta> i wonder who should update that
[20:50] <fta> jdstrand, ^^
[21:27] <jdstrand> I don't have the status on that, but I'll poke someone about it
[21:28] <jdstrand> wait
[21:28] <jdstrand> I show:
[21:28] <jdstrand> hardy: 9.3.1-1hardy2, Pocket: release, Component: partner
[21:28] <jdstrand> intrepid: 9.3.1-1intrepid1, Pocket: release, Component: partner
[21:28] <jdstrand> jaunty: 9.3.1-1jaunty1, Pocket: release, Component: partner
[21:28] <jdstrand> karmic: 9.3.1-1karmic1, Pocket: release, Component: partner
[21:28] <micahg> chrisccoulson: did we not push the 3.0.19/3.5.9 updates?
[21:28] <jdstrand> oh, lucid
[21:28] <jdstrand> yeah, partner doesn't get updated for the devel release until (or very near) the actual release
[21:36] <[reed]> jdstrand: that seems like a great way to pwn devs with access to push packages to tons of users
[21:36] <[reed]> compromised packages full of backdoors
[21:36] <micahg> [reed]: +1 :)
[21:37] <jdstrand> I didn't make the policy! :)
[21:37] <jdstrand> we've discussed it several times
[21:37] <jdstrand> people can install the one in the latest stable and it should work
[21:39] <chrisccoulson> micahg - all the updates are pushed and in the ums ppa
[21:41] <jdstrand> and by 'we' I mean our team has suggested that the partner maintainers do it. my understanding is that the upstreams (in this case adobe) doesn't want it in there, since it may be broken
[21:41] <micahg> chrisccoulson: so any reason not to move to stable/security?
[21:41] <jdstrand> I might be wrong on that. filing a bug against acroread will get the most accurate answer
[21:41] <jdstrand> micahg, chrisccoulson: I am working on them as we speak
[21:42] <micahg> jdstrand: ok, great, thanks
[21:43] <chrisccoulson> bah, i just locked Xorg
[21:44] <jdstrand> fyi, nss and 3.5 are getting published within minutes. ff3 will be a little longer
[21:49] <fta>   acroread | 9.1.0-7jaunty2 | http://archive.canonical.com/ubuntu/ lucid/partner Packages
[21:49] <fta> what am i missing??
[21:50] <fta> $ cat /etc/apt/sources.list.d/partner.list
[21:50] <fta> deb http://archive.canonical.com/ubuntu lucid partner
[21:50] <chrisccoulson> jdstrand, excellent, thanks
[21:52] <fta> oh, there's no lucid version of 9.3.1 :(
[21:53] <jdstrand> yeah, just get the karmic one
[21:54] <fta> it's bad, lucid has the old one, plenty of CVEs
[23:07] <cwillu> asac, I got that far, but will a debian/rules binary take apply the new patch, or do I have to clean first?
[23:08] <ddecator> (since this is related to nightingale): i'm using a rules file that pulls source using bzr. i have "bzr checkout [branch] [dir]" setup. the dir is defined as '$(TMP)/nightingale' which automatically puts '/tmp-#####/nightingale' but bzr only recognizes 'tmp-#####/nightingale' so is there i way i can have $(TMP) not include the first '/'?
[23:22] <asac> cwillu: clean is easiest
[23:22] <cwillu> asac, a build takes 4 hours
[23:23] <cwillu> (building for arm)
[23:23] <asac> go in build-tree/mozilla
[23:23] <asac> ln -s ../../debian/patches
[23:23] <asac> quilt push
[23:23] <asac> (to apply new patch)
[23:23] <asac> then
[23:23] <asac> make
[23:23] <asac> cd ../..
[23:23] <asac> debuild -nc
[23:23] <asac> to finish incremental packaging
[23:23]  * cwillu huggles asac
[23:23] <asac> assuming you appended it to series ;)
[23:23] <asac> (not prepended)
[23:23] <cwillu> which I did
[23:24] <cwillu> okay, I'll give that a shot tonight (left work early after firing off that build)
[23:25] <cwillu> incidently, if the patches in question cause a dramatic improvement in performance on arm like the bugs in questions claim they do, is there any chance they would be pulled in, at least for the arm port?
[23:25] <asac> cwillu: would need to see the patches
[23:25] <cwillu> of course
[23:25] <asac> cwillu: any idea about our frame issue?
[23:26] <cwillu> frame issue?
[23:26] <asac> bug 443147
[23:26]  * cwillu scrolls up
[23:26] <asac> do you see that too?
[23:27] <cwillu> haven't seen it myself, although I've only looked at a very few number of pages
[23:27] <cwillu> sec, let me read the bug
[23:27] <asac> right. open gmaps
[23:27] <asac> its always there for us
[23:27] <asac> google maps that is
[23:27] <asac> see the screenshot there
[23:27] <cwillu> I'll check it tonight, I don't have any boards here
[23:28] <cwillu> my data point might be interesting though, as I'm running at high resolutions (1024x768, 1280x1024), probably uncommon for arm I'd imagine
[23:29] <asac> well. i see it over ssh even ;=)
[23:29] <asac> so not related to xserver
[23:30] <cwillu> it's still using the local pixman and such though, and arm's resolution is generally set at boot time, not by xorg
[23:30] <cwillu> do you see it in qemu-arm?
[23:31] <cwillu> asac, don't suppose anybody's figured out the exact repo case?
[23:32] <cwillu> I could check against my source to see if I _should_ see it
[23:45] <asac> cwillu: good question. i havent checked in qemu
[23:45] <asac> might be worth a try
[23:45] <cwillu> I'll be able to check that tonight too :p
[23:45] <asac> if you have a qemu running with lucid etc.
[23:45] <asac> cool
[23:45] <cwillu> oh, is this lucid only?
[23:46] <asac> not sure
[23:46] <asac> i dont think so
[23:46] <cwillu> okay, I can check both easily enough
[23:46] <asac> but lucid is where we saw it as thats where we shipped 3.6
[23:46] <cwillu> oh, is this 3.6 only? :p
[23:46] <asac> not sure
[23:46] <asac> 3.6 and above i would think ;)
[23:46] <asac> but really not sure either. thats why i want more data ;)
[23:47] <cwillu> but not 3.5?
[23:47] <asac> i dont think we saw it there
[23:47] <asac> 3.6 is better for arm anyway
[23:47] <asac> except those frames ;
[23:47] <asac> )
[23:47] <cwillu> mmm
[23:48] <cwillu> what in particular is 3.6 better for in that way?
[23:48] <cwillu> I've got a hacked up pixman that I've been using
[23:48] <cwillu> and none of the arm performance bugs I've been following have patches commited
[23:49] <asac> cwillu: performance wise its better for arm
[23:49] <cwillu> can you be more specific?
[23:50] <asac> also its armv7 + thumb2 ready
[23:50] <asac> ;)
[23:50] <asac> also 3.5 is kind of EOL
[23:50] <cwillu> the _only_ thing that matters for arm performance in my opinion is the memory bandwidth usage
[23:50] <asac> well. upstream said they did most arm work on 3.6 ;)
[23:50] <cwillu> well, upstream is full of crap :p
[23:50] <asac> and since we moved there we didnt bother much about 3.5
[23:51] <asac> we had some javascript tests ... those were definitly better
[23:51] <cwillu> heh
[23:51] <asac> but we also changed other things like moving away from xulrunner
[23:51] <cwillu> see, these things don't matter in my experience :)
[23:51] <asac> so cant say that improvmeents i due to that or the arm improvements or whatever ;)
[23:51] <cwillu> I get 5 frames per second scrolling a page consisting of a single element
[23:52] <asac> what spec has your board?
[23:52] <cwillu> omap 3530's iirc
[23:52] <cwillu> beagles and overos
[23:52] <asac> kk
[23:52] <cwillu> there's enough there to push 60fps to the screen
[23:53] <asac> do you have proper accell?
[23:53] <asac> e.g. drivers etc.?
[23:53] <cwillu> define proper acceleration :)
[23:53] <asac> guess the free drivers in the archive?
[23:53] <asac> ;)
[23:53] <cwillu> I'm running the latest and greatest neon code for graphics, yes
[23:53] <cwillu> the issues are memory bandwidth
[23:54] <cwillu> moving to 16bits internally is supposed to help dramatically, which is what I'm testing now
[23:54] <cwillu> neon pixman helps significantly, but still not enough for things to be smooth
[23:55] <maxb> What is the outlook for enigmail at this point? Is it likely to make it into lucid?
[23:55] <asac> maxb: likely atm
[23:55] <asac> let me check something ;)
[23:57] <asac> are the ppa builders empty?
[23:58]  * asac cecks http://launchpad.net/builders
[23:58] <asac> ok seem busy ;)
[23:58] <asac> rebuild test :(
[23:58] <asac> ok going for pbuilder to check this build-depends out