[00:05] <fta> asac, http://code.google.com/p/chromium/issues/detail?id=26448
[00:32] <asac> fta: whats that?
[00:32] <asac> i mea n... in hardy we have a recent enough nss right?
[00:32] <asac> does this really happen in our built?
[00:33] <asac> we generate the lower version through symbols
[00:33] <asac> if new symbols are not used, then yeah
[00:33] <fta> i'm not sure, people with vanilla hardy? or broken symbols?
[00:35] <asac> yes. but vanilla hardy is not supported imo
[00:36] <fta> i've just been Cced to the bug, i don't any additional information
[00:37] <asac> yeah. but you said you will bump requirements ;)
[00:37] <asac> which i think is not needed. users that install vanilla hardy ... dont get fixes/updates ... so chrome is broken :)
[00:37] <asac> thats how it is ;)
[00:37] <asac> the fix for that is available in -security
[00:37] <asac> and -updates
[00:37] <asac> and all real life hardy users should have that
[00:38] <asac> even downstreams should at least track -security
[00:53] <fta> please add that to the bug
[00:54] <fta> !ping
[00:54] <fta> hm
[01:00] <fta> asac, o3d is now native x64
[01:01] <fta> and is now very similar to chromium.. gyp, scons, etc.. but it builds its own flow of libs
[01:01] <fta> incl v8 & skia
[01:05] <LlamaZorz> Hello all, I am woundering if some of you could please enlighten me on when firefox forks and gets control of the flash player?
[01:07] <micahg> LlamaZorz: what do you mean?
[01:09] <LlamaZorz>  When you are in firefox and go to a page that utilizes flash.  Does firefox create a new instantiation of flash or does it use one sole instance with a lock, im trying to figure out how that works
[08:45] <jonathan__> morningall
[10:25] <asac> fta: i think the tools/ directory should be in build-system?
[10:26] <asac> tried to build fennec with 1.9.2 build-system ... choked because build/Makefile.in wants to do something with tools/rb...
[10:29]  * eagles0513875 waves to asac :)
[10:29] <asac> hi eagles0513875
[10:30] <eagles0513875> asac: question bout lucid dev do you recommend upgrading or using a chroot environment to work on extensions
[10:30] <eagles0513875> also how then does one go about testing them in the version of firefox in karmic
[10:32] <asac> eagles0513875: i would suggest to setup chroot ...
[10:32] <eagles0513875> ok
[10:32] <eagles0513875> !chroot
[10:32] <asac> for extensions you might even not need to have lucid at all
[10:32] <asac> except maybe for a final build tests etc. you should be able to do that in karmic
[10:33] <eagles0513875> for now testing and working on karmic should be fine
[11:00] <fta> asac, yes, probably
[12:12] <stsquad> Is there any reason why the backported xulrunner-1.9.1-dev has an unsolvable mozilla-nspr>4.8.2 prerequesite in its libxul.pc?
[12:24] <stsquad> http://pastebin.com/m5c00089d
[12:24] <stsquad> Could this be due to building on a later version of Ubuntu?
[12:31] <asac> stsquad: its replaced during build time ... NSPR_VERSION=$(shell $(NSPR_CONFIG) --version)
[12:32] <asac> not sure how you backport it ... but you seem to built it somewhere where there is nspr 4.8.2
[12:32] <asac> oh yeah
[12:32] <stsquad> I'm just checking now, the current xulrunner-1.9.1-dev is from the PPA (I'm on Hardy).
[12:32] <asac> and if you dont use native nspr during build you get NSPR_VERSION=$(shell $(DEPTH)/nsprpub/config/nspr-config --version)
[12:33] <asac> yeah
[12:33] <asac> so the reason is that we fallback to in-source nspr if the system version is too low
[12:33] <asac> stsquad: you have mozilla-nspr.pc too?
[12:34] <asac> right ... so there should be a mozilla-nspr.pc ... dont we ship that?
[12:35] <asac> you can surely workaround by backporting karmic nspr first ... so we use system-nspr
[12:35] <asac> or did you already backport nspr 4.8 from karmic?
[12:36]  * stsquad looks
[12:37] <stsquad> The only nspr I have is libnspr4-dev from Hardy's repos (which I assume must be the right one as FF3.5 is running)
[12:37]  * stsquad checks ldd
[12:38] <asac> stsquad: no
[12:38] <asac> the one in hardy is too old
[12:38] <asac> it will fallback to in-source nspr
[12:38] <asac> backport the karmic nspr + nss
[12:38]  * stsquad is confused
[12:39] <asac> then build the xulrunner 1.9.1
[12:39] <stsquad> xulruner packages an libnspr4.so
[12:39] <asac> stsquad: dpkg -L xulrunner-1.9.1 | grep nspr
[12:39] <asac> yes
[12:39] <asac> thats the in-source one
[12:39] <asac> so if system-nspr is too low our build system reverts to its own nspr
[12:39] <asac> however, building against that is a bit busted (upstream)
[12:39] <asac> would probably required a few fixes
[12:40] <asac> stsquad: do you need libxul.pc? maybe check if libxul-embedding.pc is what you want (for standalone applications its the right thing to do and libxul.pc is just for plugins and components that get loaded in a running xulrunner)
[12:40] <stsquad> So the in source nspr is only for FF itself, it can't be used for embedding?
[12:41] <stsquad> With the system FF (3.0) I was using pkg-config --exists xulrunner-gtkmozembed
[12:41] <stsquad> I'm now using  pkg-config --exists mozilla-gtkmozembed which pulls in libxul.pc
[12:41] <asac> stsquad: thats a red herring ... if you embed gecko you must not use that
[12:41] <asac> some redhat guy pushed for that ... and hte name is confusing
[12:42] <stsquad> So the correct pkgconfig for embedding gecko is?
[12:42] <asac> you need to use the standalone glue ... whihc is libxul-embedding-unstable
[12:42] <asac> or libxul-embedding
[12:42] <asac> https://developer.mozilla.org/en/xpcom_glue
[12:43] <asac> also check this: https://wiki.ubuntu.com/XulrunnerGecko
[12:43] <asac> which gives info what needs to be done to port stuff from 1.8 (which stil used mozilla-gtkmozembd) to 1.9+
[12:43] <asac> might be a bit outdated here and then but in general should be right
[12:44] <asac> search for #ifdef XPCOM_GLUE
[12:44] <asac> on that wiki page
[12:44] <asac> thats basically the code you need to properly use the xpcom glue
[12:44] <stsquad> Ahh so the calls in the app to gtk_moz_embed_new etc need to be changed to use xpcom  glue instead
[12:49] <stsquad> asac: thanks for the pointers, I think I know what I need to fix now
[12:59] <asac> stsquad: more or less yes. there are a few implications though: e.g. you must not use internal symbols etc. just xpcom interfaces
[13:00] <asac> but you shouldnt use those internal symbols anyway
[13:14] <fta> ~5 new dupes a day for the scim crash bug :(
[13:31] <mac_v> fta: i was also subscribed to that bug , finally i got fed up and unsubscribed ;)
[13:32] <mac_v> asac: why does updating firefox always reinstall the search engines? I remove them and they keep getting installed with every update :(
[13:33] <fta> mac_v, yep, i just unsubscribed too
[13:34] <asac> mac_v: thats a bug
[13:35] <mac_v> asac: oh , good...  i was worried it was intentional ...  \o/
[13:35]  * mac_v now searches for bug :)
[13:36] <asac> its probably the same as the "keywords wiped" things
[13:36] <asac> thing
[13:36] <asac> in launchpad
[13:36] <asac> havent found time to investigate
[13:37]  * mac_v wonders if anyone still uses yahoo search engine o.0
[13:39] <mac_v> ah found it.. Bug #428306
[15:12] <asac> darn ... this about: stuff kills me ;)
[15:21] <fta> about?
[15:35] <asac> yes its a mess ... supposed to fix ubufox with about:ubuntuhome about:offlinehome ...
[15:49] <asac> fta: is anything needed besides chromium-browser to build chromium?
[15:49] <asac> like is there a build depends ppa still?
[17:18] <fta> asac, no, the build-dep ppa is not ready, i had issues with cdbs backports
[17:20] <fta> asac, http://codereview.chromium.org/174162 (last comment), what do you think?
[18:15] <asac> fta: not sure. i think its ok to keep inspector if thats the user experience chrome folks want to ship
[18:15] <asac> http://launchpadlibrarian.net/35579379/buildlog_ubuntu-karmic-armel.chromium-browser_4.0.245.0~svn20091111r31665-0ubuntu1~ucd1_FAILEDTOBUILD.txt.gz
[18:15]  * asac spins chromium on porter box
[18:21] <fta> chromium-browser                 19439   1.48%      3512    8849    7074       4
[18:21] <fta> chromium-browser-inspector         964   0.07%        70     170     724       0
[18:22] <fta> asac, the initial idea was that if less than 5% of the users really need that, it's not worth making it a hard dep
[18:22] <fta> we are at 4.96% now
[18:32] <asac> fta: right. but if upstream thinks they want such a rarely used thing by default then there is no point fighting it ... also atm folks using chromium are of the "lets try it" kind ... so they install -inspector with higher likelyhood than normal users.
[18:33] <asac> fta: how can i continue a build when i fixed something without making full clean?
[18:33] <asac> (chromium-browser)
[18:37] <asac> fta: in common.gypi there is 'armv7%': 0, ... is that something we have to set to 1? or are those variables detected somewhere
[18:37] <asac> ?
[18:39] <asac> e.g. do i need to put that in GYP_DEFINES or somehting? i would hope that its auto detected (which as it seems it isnt)
[18:42] <fta> it's not
[18:44] <fta> well, supposedly, there's target_arch='<!(uname -m | sed -e "s/i.86/ia32/;s/x86_64/x64/;s/arm.*/arm/")'
[18:45] <asac> fta: right. target probably is right
[18:45] <fta> try to add armv7=1
[18:45] <asac> but in common.gypi there also is armv7% : 0
[18:45] <asac> right
[18:45] <asac> fta: is there a way to incremental build?
[18:45] <asac> hmm its not a patch ... let me just respin
[18:46] <asac> building
[18:46] <asac> ...
[18:46] <asac> lets see
[18:47] <asac> name 'armv7' is not defined while evaluating condition 'armv7==1 and _toolset=="target"' in
[18:47] <asac> that feels a bit odd though
[18:47] <asac> it should at least be 0
[18:47] <asac> what does that % mean?
[18:47] <asac> is that gypi syntax?
[18:49] <asac> fta: https://wiki.mozilla.org/Releases/Thunderbird_3.0rc1#Build_Revisions
[18:49] <asac> can we produce a tarball based on such revisions?
[18:50] <asac> i assume we cannot specify two/three different revisions for comm-central/mozilla-central
[18:50] <fta> i know, they made THUNDERBIRD_3_0rc1_RELEASE earlier today
[18:50] <asac> oh there i THUNDERBIRD_3_0rc1_BUILD1
[18:50] <fta> it's not needed
[18:50] <asac> yeah
[18:50] <asac> in comm-central there is no such tag as it seems
[18:51] <asac> at least i dont see it in hg.mozilla.org/comm-central
[18:51] <fta> just grab tb3 with that tag, it will fetch the right wul
[18:51] <asac> oh wait ... maybe its a branch
[18:51] <fta> it's in a branch
[18:51] <fta> that's why i've made a tb3.1 package
[18:52] <fta> i should add it to the bot
[18:52] <fta> but with that silly restriction..
[18:52] <fta> same for lucid
[18:52] <asac> no such tag for comm-central :(
[18:52] <asac> oh in releases
[18:52]  * asac checks
[18:53] <asac> got it i think
[18:53] <asac> good
[18:53] <fta> mozclient should do that for you
[18:53] <asac> yeah
[18:53] <asac> i just didnt find it at all
[18:53] <asac> ;)
[18:53] <asac> now i have it
[18:53] <fta> ?
[18:54] <fta> just get-orig-source as usual
[18:54] <asac> fta: i looked in comm-ncetral ... not comm-1.9.1
[18:54] <fta> i use the RSS feeds
[18:54] <fta> http://hg.mozilla.org/releases/comm-1.9.1/atom-tags
[18:54] <fta> http://hg.mozilla.org/comm-central/atom-tags
[18:54] <asac> good ... i think chromium beuilt got past that gypi thing
[18:55] <asac> now waiting
[18:55] <asac> yeah
[18:55] <fta> http://hg.mozilla.org/releases/mozilla-1.9.2/atom-tags
[18:55] <fta> etc
[18:55] <asac> yep
[18:56] <asac> hmm the comm-central revisions http://hg.mozilla.org/releases/comm-1.9.1/rev/6ec88ca5bf7a seems to not have that BUILD1 tag
[19:01] <fta> i don't see a BUILD tag, just RELEASE
[19:08] <fta> [reed], can you steal the fix from the tracemonkey branch?
[19:09] <[reed]> fta: yeah, should be able to
[19:09] <[reed]> let me check when TM is going to be merged next
[19:10] <[reed]> if it's going to be a while, I'll just push it to m-c
[19:11] <fta> ok
[19:18] <asac> fta: Linux jocote 2.6.28-14-lange51 #46arm1 Thu Aug 6 23:33:27 CST 2009 armv7l GNU/Linux
[19:18] <asac> whats the best way to make that "dynamic"?
[19:19] <fta> what do you mean?
[19:19] <asac> e.g. in upstream build system
[19:19] <fta> what is uname -m ?
[19:19] <asac> fta: make armv7 : 1 in common.gypi if its armv7* i guess
[19:19] <asac> armv7l
[19:20] <asac> is uname -m
[19:20] <fta> yes then
[19:22] <fta> check uname -m for armv7 in the armel test
[19:22] <fta> why did you add a test using DEB_BUILD_ARCH instead of DEB_BUILD_GNU_CPU?
[19:22] <fta> asac, ^^
[19:39] <asac> fta: isnt BUILD_ARCH right? e.g. in case someone wants to cross-compile?
[19:46] <fta> both should work, but GNU_CPU is less ubuntu specific, it matches hw better
[19:46] <fta> DEB_BUILD_ARCH_CPU=i386
[19:46] <fta> DEB_BUILD_GNU_CPU=i486
[19:46] <fta> DEB_BUILD_ARCH=i386
[19:47] <fta> and i wanted a generic x64 instead of amd64
[19:47] <fta> er, x86_64
[19:48] <fta> asac, ^^, could plz pastebin dpkg-architecture ?
[19:50] <asac> http://paste.ubuntu.com/317197/
[19:52] <BUGabundo> howdy
[19:52] <BUGabundo> sick man entering the room
[19:57] <fta> asac, so DEB_BUILD_GNU_CPU=arm is nice, use that to set both target_arch=arm & armv7=1
[19:59] <asac> fta: are you sure that GNU_CPU has the host arch?
[19:59] <asac> like for cross-compiling and stuff?
[20:01] <fta> it's BUILD.*CPU, not HOST.*CPU
[20:01] <fta> cdbs knows about both
[20:07] <fta> ok, nice, i build xul in less than 12 minutes incl the pbuilder setup
[20:07] <micahg1> fta: how?
[20:08] <fta> by using all cpu/cores available
[20:08] <fta> committed in the 1.9.3 branch
[20:09] <fta> they don't want us to take a lot of builder time, so we'll take power more for each builder
[20:09] <fta> (more misplaced)
[20:13] <fta> micahg, it won't help if you just have 1 cpu
[20:13] <micahg> that's good
[20:15] <fta> but then, locally, you can use distcc, or ccache
[20:15] <fta> too bad the builders are just dual core, not quad or more
[20:16] <fta> asac, http://code.google.com/p/chromium/wiki/LinuxChromiumArm
[20:19] <BUGabundo> 85% [145 xulrunner-1.9.3-dbg 22299555/64.0MB 34%]                                                                         69.1kB/s 10min 3s
[20:19] <BUGabundo> can't you guys make this any smaller??
[20:19] <BUGabundo> its taking FOR EVER
[20:20] <fta> Fetched 262MB in 5min 14s (833kB/s)
[20:20] <fta> that's still slow though
[20:21] <BUGabundo> right
[20:21] <BUGabundo> now imagine ALL LUCID updates
[20:21] <BUGabundo> not done in a week
[20:21] <BUGabundo> Need to get 293MB of archives. After unpacking 229MB will be used.
[20:22] <BUGabundo> the mere package list is HUGE
[20:22] <BUGabundo> Fetched 18.4MB in 1min 36s (191kB/s)
[20:23] <fta> i can use lzma, but asac said it's not acceptable, for some reason
[20:24] <fta> i use lzma for chromium only
[20:24] <fta> as it's not in the repo
[20:24] <fta> to lzma just the -dbg, it will mean patching cdbs
[20:28] <BUGabundo> bah
[20:28] <BUGabundo> I'm purging -dbg packags
[20:29] <BUGabundo> 285 MBs freed :)
[20:33] <hackel> Is there any ppa that just carries Mozilla's "releases" (e.g. FF 3.6 beta 2) instead of updating every day?
[20:33] <BUGabundo> yes
[20:33] <BUGabundo> mozilla security ppa
[20:34] <BUGabundo> !g mozilla security ppa
[20:34] <BUGabundo> https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa
[20:34] <hackel> BUGabundo:  Ahh, but it doesn't have 3.6 yet, I checked.
[20:34] <BUGabundo> it doesn't?
[20:34] <BUGabundo> fta care to help ?
[20:35] <micahg> hackel: I built it, but I have to fix the branding still
[20:35] <micahg> https://edge.launchpad.net/~micahg/+archive/mozilla-beta
[20:35] <micahg> BUGabundo: mozilla security is security releases :)
[20:35] <micahg> of stable versions
[20:37] <hackel> micahg:  thanks I'll give that a try, I'm not fussy about branding. :)
[20:37] <micahg> hackel: yeah, but we're not supposed to have official branding for pre-releases
[20:38] <hackel> Oh, you mean it actually says Firefox instead of Namoroka or whatever?
[20:38] <micahg> yes
[20:38] <hackel> I won't tell anyone. ;)
[20:40] <BUGabundo> fta is there a "open in new tab from memory" shortcut on chromium?
[21:28] <fta> asac, micahg1, BUGabundo: http://paste.ubuntu.com/317269/
[21:28] <bdrung> asac: around?
[21:29]  * BUGabundo checks fta virus
[21:35] <fta> micahg1, didn't you bump cairo in xul 1.9.2?
[21:37] <micahg1> hmm
[21:37] <micahg1> idr
[21:37] <micahg1> I've been bumping as the warnings happen
[21:37] <micahg1> nope, not yet
[21:37] <micahg> did it on 1.9.1 and ff3.5
[21:38] <micahg> and TB3
[21:39]  * BUGabundo is seeing doubles
[21:39] <micahg> fta, you're starting lucid builds?
[21:39] <fta> yes
[21:39] <fta> all ppa will explode
[21:40] <micahg> fta, I'll bump xul192 and ff36 tonight
[21:40] <fta> i need to add tb3.1 too
[21:40] <fta> probably need fixes too
[21:40] <micahg> fta: songbird patches, do I need to be in the outside build-tree to use them?
[21:41] <micahg> for xul and ff, I go into build-tree/mozilla and work there
[21:41] <fta> you need to be where the .pc folder is
[21:42] <micahg> so the .pc folder is created during debuild?
[21:42] <fta> it's created by quilt, so during the patch step, before configure
[21:43] <micahg> ok, got it, I'll try to get the patches up to date over the weekend then
[21:44] <fta> damn, i ordered two things from amazon us, they ungrouped them
[21:46] <fta> lol "estimated delivery date: December 22, 2009"
[21:49] <fta> can anyone play this smoothly? http://vimeo.com/6686768
[21:50] <fta> i can't, neither with ff, nor with chromium
[21:51] <bdrung> asac: please release m-d as version 0.17.1 (i want this rc bug fixed)
[21:54] <micahg> fta, seems mostly smooth with the occasional audio hiccup
[21:54] <micahg> ff3.6b2
[21:55] <fta> with 3.7, the sound is jerky, like every 3 secs, so the video sometimes stops
[21:55] <fta> the browser is at 100% cpu, so the plugin probably lacks resources to play smoothly
[21:56] <fta> it's a dual core 2.3GHz
[21:56] <fta> dtchen_, ^^
[21:58] <fta> micahg, asac: http://paste.ubuntu.com/317291/
[21:58]  * micahg will be waiting for it to break tomorrow :)
[21:58] <av`> bdrung, which RC bug?
[21:58] <av`> bdrung, you can upload it yourself
[21:59] <bdrung> av`: i can upload it, but not sponsor it
[21:59] <hackel> fta:  plays perfectly with mplayer.  Flash has never played video well for me.  Great video, by the way...
[21:59] <av`> bdrung, ?
[22:00] <bdrung> av`: https://code.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts
[22:00] <bdrung> commit 274
[22:01] <av`> bdrung, re-link it again please, lost the window
[22:01] <fta> hackel, yep, i love timelapses, i'm trying to make my own videos, but linux mostly sucks for photography :(
[22:01] <bdrung> av`: ?
[22:02] <av`> bdrung, re-link me the branch
[22:02] <bdrung> av`: can't you scoll up to this post? https://code.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts
[22:03] <fta> av`, it's a native package, don't release stuff without going to asac or myself
[22:03] <av`> bdrung, yes, works now
[22:03] <fta> we need to make an "upstream" release
[22:03] <av`> fta, actually bdrung is one of the authors
[22:04] <av`> fta, plus m-ds has an R-C bug that makes it unusable atm
[22:04] <av`> so I don't know if we can wait long to have it uploaded
[22:04] <fta> still not a reason to do a wild upload
[22:05] <av`> I don't think bdrung would do a wild upload
[22:05] <fta> iirc, asac said he'll do it
[22:05] <micahg> av`: there are versions in the u-m-d ppa
[22:06] <bdrung> fta: are you a DD?
[22:06] <av`> ok, great, I saw bdrung was asking several times about it so I didnt understand why he couldnt upload it himself
[22:06] <fta> no, but i'm upstream for this package, i've created it
[22:06] <bdrung> fta: it's a bug fix and a point release (0.17 -> 0.17.1) would fit, wouldn't it?
[22:07] <av`> micahg, it's not a local fix, buildds doesnt work with the current release
[22:07] <av`> micahg, so it needs to be pushed to the archive and not locally, since the buildd gets the latest package built
[22:07] <micahg> ah, you're saying nothing will compile in the builders
[22:07] <fta> initially, i just wanted X.Y (a float), but well, i don't mind
[22:07] <micahg> got it
[22:08] <av`> micahg, exactly, it fails to build cause of that RC bug :)
[22:08] <bdrung> jazzva is not on the uploaders list. so sponsoring would not work. then i can upload it, too.
[22:08] <av`> fta, jazzva used 0.18 not 0.17.1 from what I saw
[22:08] <av`> bdrung, no, you can't
[22:09] <bdrung> av`: ?
[22:09] <av`> bdrung, the changelog's entry should be owned by you
[22:09] <av`> bdrung, the changelog's entry should be owned by you
[22:09] <bdrung> av`: yes, i have to change the ownership
[22:09] <av`> = your name must appear into the changelog latest entry
[22:09] <av`> yes, exactly
[22:10] <bdrung> av`: the changelog owner needs to be in the uploaders list
[22:10] <av`> yes
[22:10] <av`> but you must be the changelog owner to have the upload accepted
[22:10] <bdrung> it is required to change it anyway
[22:11] <av`> so uploaders list + ownership of changelog's entry
[22:11] <bdrung> av`: yes, i will change this if i upload the package
[22:11] <av`> k, perfect
[22:11] <av`> but anyway ask to fta or asac, I don't wanna set up a war for a bug fix :)
[22:12] <bdrung> fta: am i allowed to upload it to debian?
[22:13] <bdrung> fta: do you prefer 0.17.1 or 0.18?
[22:13] <bdrung> asac: ^
[22:14] <fta> upload yes, but only once it has been closed. and as i'm not in sync myself, i want asac to close it
[22:14] <fta> that's what i meant by upstream
[22:14] <fta> sorry, i'm tired, tough to write tonight
[22:15] <bdrung> fta: what do you mean with closed?
[22:15] <fta> +T
[22:15] <fta> the UNRELEASE to xx commit
[22:16] <bdrung> fta: with uploading i meant changing UNRELEASE to xx, commit and tag it, and then upload it
[22:18] <fta> then we need to agree if there's enough stuff in to make the release, or if we have other stuff in the queue to stick in
[22:18] <fta> as i said, i lack context, so i won't do it myself, sorry
[22:19] <bdrung> fta: i don't know any stuff.
[22:19] <bdrung> fta: so it's better to release this one commit bug fix.
[22:20] <bdrung> fta: release often, release early - especially bug fixes
[23:44] <dtchen_> fta: if a PA client requests low latency, PA is happy to grant that at the expense of high cpu utilization
[23:44] <dtchen_> fta: this is a consequence of the mainloop
[23:46] <fta> dtchen_, is there a way to mitigate that? i mean, slightly higher latency in exchange for less cpu?
[23:46] <fta> so playback becomes smooth again
[23:48] <dtchen_> well, yes, the PA app needs to be changed
[23:48] <dtchen_> I'll try to push a PPA version soon
[23:48] <dtchen_> time. I never have enough.
[23:54] <fta> dtchen_, would it help to have daily p-a PPA?
[23:54] <fta> +a
[23:54] <dtchen_> fta: no
[23:55] <dtchen_> I discussed this with PA upstream at the beginning of the Karmic cycle, and he said it wouldn't be particularly useful, because changes aren't committed to the public VCS daily
[23:55] <fta> hmm
[23:56] <dtchen_> note that I wouldn't mind having one, but he seems indifferent to it, which is somewhat baffling