[11:43] <BUGabundo> asac: ping
[11:43] <BUGabundo> Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20090503 Ubuntu/9.04 (jaunty) Minefield/3.6a1pre ID:20090503175558
[11:43] <BUGabundo> but I'm on karmic
[11:43] <BUGabundo> why didn't FF update?
[11:51] <asac> BUGabundo: karmic dailies == non-existing ;)
[11:51] <BUGabundo> ahhhh right
[11:51] <BUGabundo> how I miss fta
[11:51] <BUGabundo> long vacation, enh ?
[11:51] <asac> ;)
[11:52] <asac> yeah.
[11:52] <BUGabundo> he is not even updating identica
[11:52] <asac> he has no access to computer afaik
[11:52] <BUGabundo> he went DEEP offline
[11:53] <BUGabundo> FTA: @bugabundo: ask @macno  ;) Published about  23 days ago
[11:53] <BUGabundo> asac: how can any geek leave 23 days without a computer?
[11:53] <BUGabundo> :p
[11:53] <BUGabundo> so asac I've been hearding about this PGO thing for FF
[11:53] <BUGabundo> is it any good ?
[11:54] <asac> we dont know yet for sure. but most likely it helps getting a performance boost
[11:54] <BUGabundo> and are we having it ?
[11:55] <asac> no ... not yet.
[11:55] <asac> but really soon i hope
[11:56] <BUGabundo> http://www.tuxradar.com/content/benchmarked-firefox-javascript-linux-and-windows-and-its-not-pretty
[11:56] <BUGabundo> ppl love to make charts
[11:56] <BUGabundo> eheh
[11:58] <BUGabundo> asac: more on PGO http://ubuntuforums.org/showthread.php?t=1043592
[12:06] <Drune> hi guys. There is any problem building firefox with PGO? Or it just _don't_build?
[12:08] <BUGabundo> Drune: asac said it would be soon
[12:08] <BUGabundo> I just don't know what it blocking it
[12:08] <BUGabundo> [free] time I guess
[12:09] <Drune> maybe it's just dont build with gcc and PGO enable.
[12:09] <Drune> https://bugzilla.mozilla.org/show_bug.cgi?id=418866
[12:09] <Drune> Lot's of problems going here
[12:09] <asac> Drune: problem is a) nobody found time to do it ... and b) its a bit different to upstream PGO, because we need to profile xulrunner and not firefox (or well at least xulrunner is the main code)
[12:12] <Drune> c) Building it with GCC4 is so hard that everybody gives up :)
[12:14] <asac> he?
[12:14] <asac> no
[12:14] <asac> we build stuff with gcc4 since ages
[12:14] <Drune> but without PGO
[12:15] <asac> why is that hard?
[12:16] <Drune> because it just don't build, jemalloc errors, corrputed profiling files, etc
[12:16] <Drune> Do you know anybody who have made a build of firefox pgo on ubuntu? :)
[12:17] <asac> i would think you are doing somthing wrong ;)
[12:17] <asac> but we will see
[12:17] <asac> maybe there are patches needed
[12:18] <asac> i will be looking at this real soon
[12:18] <Drune> me and the rest of the world who tries to build it :)
[12:18] <Drune> it's so hard that already exists a path to skip PGO on jemalloc build :)
[12:19] <Drune> asac, thanks for your explanation
[12:19] <asac> Drune: yeah. sorry i cant tell more. i just know that other distros already have pgo builds
[12:20] <asac> at least someone pointed me to a pgo build at some point ;)
[12:20] <asac> but i will see soon
[12:20] <Drune> yes, seems that ArchLinux it's getting there
[12:20] <Drune> not a clean PGO build, but it's satisfatory
[12:20] <asac> Drune: how can oyu have a non-clean PGO build?
[12:22] <Drune> patching it to skip several things of PGO scope. On Windows you don't need to skip jemalloc from being compiled with PGO. On Linux you need that, otherwise you won't be able to compile it.
[12:22] <Drune> Check this patch: https://bug418866.bugzilla.mozilla.org/attachment.cgi?id=305385
[12:23] <asac> mozillla bug 418866
[12:23] <asac> mozillla bug 418866
[12:23] <asac> mozilla bug 418866
[13:11] <asac> Drune: https://bugzilla.mozilla.org/show_bug.cgi?id=418866#c36
[13:11] <asac> so 4.4 seems to be fine
[13:11] <asac> which we have in karmic
[13:16] <asac> yeah. still seems to be problematic though
[13:16] <asac> jemalloc was always a mess
[13:19] <Drune> :)
[13:24] <asac> wonder if anyone has tried something simple like using g_malloc ;)
[13:24] <asac> instead of jemalloc
[13:27] <Drune> not possible i guess
[13:28] <asac> err
[13:28] <asac> thats stupid
[13:28] <asac> its definitly possible ,)
[13:28] <asac> its a nspr thing
[13:29] <asac> my bet is either they tried it or want to have the same stuff on all platforms ;)
[13:29] <asac> they tried it == tried it and found that it doesnt give the same boost as jemalloc
[13:32] <Drune> yes
[13:32] <Drune> jemalloc is called as new feature
[13:32] <asac> i know about all that. i still dont like it ;)
[13:35] <Drune> firefox with some javascript eats all my cpu
[13:35] <Drune> that's sad :(
[13:36] <asac> i dont think it will go away because of PGO
[13:36] <asac> most performance issues are in graphics driveres
[13:36] <asac> really
[13:36] <asac> everything else is just fun-sport on top
[13:36] <asac> not sure what your javascript does
[13:37] <asac> Drune: you should try firefox-3.5/3.6 from daily archive
[13:37] <asac> let us know if it works better
[13:37] <Drune> asac, yes i know
[13:37] <Drune> can you point me the link for download plz?
[13:37] <asac> Drune: https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
[13:40] <Drune> installing..
[13:43] <Drune> well
[13:44] <Drune> it's working fine for now
[13:44] <Drune> faster
[13:44] <asac> Drune: 3.5? or 3.6?
[13:46] <Drune> 3.5
[13:46] <Drune> never heard of 3.6
[13:46] <asac> 3.6 is trunk
[13:46] <asac> e.g. where all the current development happens
[13:47] <Drune> ah ok :)
[13:47] <Drune> still prefer 3.5
[13:47] <Drune> i need a stable desktop
[14:25] <asac_> another reconnect
[14:25] <asac_> what a messy connection again ;)
[14:27] <BUGabundo> asac mine is on 2G and as been for 15min
[14:27] <BUGabundo> stable
[14:27] <BUGabundo> eheh
[14:27] <BUGabundo> as stable as 2G can be
[14:27] <BUGabundo> lol
[14:28] <BUGabundo> asac by the way: 50% when I press disconect nothing happens! known bug?
[14:30] <asac_> i think i heard something yeah
[14:30] <asac_> i thought it was the modemmanager build that had that
[14:31] <BUGabundo> NM here
[14:31] <BUGabundo> should I file it and search for dupes?
[14:35] <asac> gimme a few minutes ... have to download all bugmails ;)
[14:41] <BUGabundo> eheh asac
[14:41] <BUGabundo> I'm out too
[14:41] <BUGabundo>  LUG meeting
[14:42] <BUGabundo> bbl
[16:11] <asac> 17:07 < asac> hmm ... i cannot push to launchpad (bzr) ... ssh server problem?
[16:11] <asac> 17:11 < asac> anyone else sees this?
[16:15] <BUGabundo1> asac: I don't push much
[16:15] <asac> heh
[16:15] <BUGabundo1> but it could be the timeouts
[16:15] <asac> ok
[16:15] <asac> someone in launchpad showed up with the same problem
[16:15] <asac> so seems there is a general issue with lp
[16:16] <sebner> the issue is lp  ^^  /me waves at asac btw :D
[16:16] <asac> hehe yeah. hi!
[16:16] <asac> i managed to push now
[16:16] <asac> good
[16:16] <asac> ;)
[16:16] <asac> just took ages
[18:05] <asac> BUGabundo: pushed dailies for karmic manually ;)
[18:05] <asac> so in 1-2 hours or so it might be your time ;)
[18:06] <dtchen> asac: does linux-image-2.6.28-12.43-generic (jaunty-proposed) make pulseaudio work (or be tolerable) for you, whereas the release (linux-image-2.6.28-11.42-generic) does not?
[18:07] <dtchen> asac: if so, please comment in bug 345627
[18:07] <dtchen> i need to get a feel whether my commits need to be reverted, because so many people are complaining about other errors
[18:07] <asac> dtchen: i am running #43 and that works well
[18:07] <asac> but it worked well now since you said to me to test proposed
[18:08] <asac> e.g. i think #42 was good as well
[18:08] <BUGabundo> asac: thanks
[18:08] <BUGabundo> asac: even for 64 bits? are buildds back online?
[18:08] <asac> dtchen: when was #43 rolled out?
[18:08] <dtchen> asac: ok, so what i'm interested in - if you have the time - is if you see regressions between 11.42 and 12.43 in terms of audio
[18:09] <asac> dtchen: #43 works really good so far. so i definitly dont see regressions from #42
[18:09] <dtchen> may 2nd-ish
[18:09] <asac> hmm
[18:09] <asac> was that when you said i should add the ppa?
[18:09] <asac> err -proposed
[18:09] <asac> anyway ... lets see if i can downgrade the kernel
[18:10] <asac> dtchen: is #42 still the normal archive?
[18:10] <asac> oh i even still have it
[18:10] <dtchen> asac: it should be available in your grub menu choices if you haven't manually removed it
[18:10] <asac> (it was -11)
[18:10] <dtchen> right
[18:10] <asac> dtchen: do i need to downgrade pulse too?
[18:10] <dtchen> no
[18:10] <asac> or are you only interested in kernel
[18:10] <asac> ah ok
[18:10] <asac> yeah ... let me reboot
[18:11] <asac> ok bbim
[18:25] <asac> dtchen: seems still good. guess for me most issues were in pulse?
[18:25] <asac> dtchen: only problem that - afaik came back - is that totem kills sound
[18:26] <asac> but i havent used totem with the other kernel
[18:26] <dtchen> can you try totem on the other kernel, too, to attempt to reproduce it?
[18:26] <asac> so i dont know if its the same ... let me boot the other kernel again
[18:26] <asac> yeah
[18:26] <asac> i can check that
[18:26] <asac> but the real problems i had were really worth. now after the totem issues things recover and flash and all stuff work again after reload
[18:27] <asac> previously once i managed to kill sound it would go nuts ... e.g. strange sounds
[18:27] <asac> with accellerated video and stuff like that
[18:27] <asac> and dying pulse process
[18:27] <asac> ok rebooting again
[18:33] <asac> dtchen: yeah so that problem also exists in the new kernel
[18:33] <asac> gstreamer seems to have a general issue i guess
[18:33] <dtchen> ok, thanks much
[18:33] <asac> but totem is a mess anyway ... whatever it uses for video its just plain slow with my driver
[18:33] <asac> so maybe its a buffer underflow thing or something :)
[18:33] <asac> welcome
[18:34] <asac> so i didnt really use -11 for a long time now, but from what i saw there are no regressions if those changes get backed out
[18:34] <asac> i will switch more permanently to -11 if you want
[18:34] <asac> dtchen: ?
[18:34] <asac> e.g. is backing out the -12 changes currently the idea?
[18:35] <asac> dtchen: May  9 19:32:08 hector pulseaudio[4066]: cpulimit.c: Received request to terminate due to CPU overload.
[18:35] <asac> thats what i see in syslog when totem kills sound
[18:35] <asac> interestingly restarting totem didnt fix it (e.g. sound was off)
[18:35] <asac> but i had to start gmplayer with -ao pulse once (which worked)
[18:36] <asac> and then totem worked again until it killed sound
[18:36] <asac> again
[18:36] <dtchen> right, ok.
[18:36] <asac> dtchen: so CPU overload sounds really like gstreamer has issues with overload + pulse
[18:36] <dtchen> that's the symptom everyone else is seeing
[18:36] <asac> ah ...so thats the bug you are currently investigating?
[18:36] <dtchen> yes
[18:36] <asac> ok. in anycase. whatever came through -proposed fixed a bunch of much worse issues
[18:37] <asac> (except the kernel)
[18:37] <asac> so i guess the pulse changes are fine
[18:37] <asac> i remember that i had this totem issue even when i had all the other issues
[18:38] <dtchen> what a clusterfsck
[18:38] <asac> dtchen: smells a bit like gstreamer bug to me ... flash + gmplayer with pulse works perfect
[18:38] <asac> well at least gstreamer uncovered bug
[18:38] <asac> pulse could probably recover better ;)
[18:39] <asac> let me check if its an issue in gnash too ... which uses gstreamer
[18:39] <asac> hopefully it doesnt cause this excessive CPU usage
[18:50] <asac> dtchen: gnash is ok too ... doesnt trigger this issue
[18:50] <asac> even when i slow down system
[18:51] <dtchen> hmm
[18:52] <dtchen> there are a ton of pulsesink fixes in git GSt/plugins/good
[18:54] <dtchen> asac: how about multiple writers to the pulsesink, like multiple youtube videos simultaneously?
[18:57] <asac> dtchen: with adobe? or gnash?
[18:58] <dtchen> asac: both, preferably
[18:59] <asac> dtchen: how many == multiple?
[18:59] <dtchen> three or more
[19:02] <asac> dtchen: so #43 is unbreakable .…. except totem
[19:03] <asac> gnash ... adobe flash ... gmplayer with -ao pulse work well in parallel
[19:03] <dtchen> what the heck is totem (or GSt or whatever) doing?
[19:03] <asac> it must be totem ... gnash uses gst too
[19:03] <asac> but i definitly had CPU utilized too with gnash now
[19:03] <asac> didnt see any pulseaudio "CPU overloaded" message
[19:04] <asac> esdsink.c(411): gst_esdsink_write (): /GstPlayBin:play/GstBin:abin/GstBin:audiosinkbin/GstGConfAudioSink:audio-sink/GstBin:bin5/GstEsdSink:esdsink1:
[19:05] <asac> system error: Connection reset by peer
[19:06] <asac> May  9 20:06:05 hector pulseaudio[6179]: cpulimit.c: Received request to terminate due to CPU overload.
[19:06] <asac> why do i need to start gmplayer once? and that helps?
[19:06] <asac> let me check if gnash cures the state too
[19:08] <asac> yeah ... so gnash cures ... even though it uses gstreamer
[19:08] <dtchen> if the pulse daemon die, it will respawn automatically upon the next client attempting to connect
[19:08] <dtchen> dies*
[19:09] <asac> dtchen: yeah. but why doesnt it do that for totem?
[19:09] <asac> or well. totem doesnt complain that no sound server is there
[19:09] <asac> its just that there is no sound at all until i use some other sound app
[19:09] <dtchen> odd
[19:09] <asac> let me try multiple times ;)
[19:10] <asac> so yeah totem doesnt restart pulse
[19:12] <dtchen> thanks so much for testing
[19:13] <asac> dtchen: what would trigger the pulse restart? e.g. which lib does it ... and when?
[19:19] <asac> grabbing some food
[19:22] <dtchen> asac: libpulse0 -> libpulsecore9 -> pulseaudio
[20:13] <kklimonda> hey, is someone working on google gears package?
[20:53] <dtchen> ouch, those GSt fixes are incredibly invasive