[00:03] <sebner> asac: is it normal then when I open a mail (new tab) and delete it that nothing happens (tab description is now "Inbox") but the mail remains, with TB2 the mail was deleted and the next mail opened automatically (I'm seeing this on windows though)
[00:03] <asac> for me that worked a while ago in 3
[00:03] <sebner> oh
[00:03] <sebner> now it does too
[00:03] <sebner> strange
[00:03] <asac> yeah
[00:04] <asac> there are some focus issues maybe
[00:04] <sebner> The magic of opensource hnmm?
[00:04] <sebner> yeah might be, I'll take a deeper look if it's reproducable
[00:04] <asac> the magic of opensource is that you can fix it if its annoying enough to invest that time ;)
[00:04] <sebner> Nah, the magic of opensource is that stuff that seems b0rken works out of a sudden
[00:05] <sebner> ;-P
[00:05] <micahg> asac: not sure what to do with bug 490615
[00:05] <asac> i dont think thats a specific opensource property ;)
[00:05] <asac> micahg: reproduciable?
[00:06] <sebner> asac: haha, but actually seen there quite often :D btw, when will TB3 enter the archive and become default? I hope I haven't overread something in the backlog
[00:06] <micahg> asac: I couldn't on the music site and I don't have a safari account
[00:06] <asac> sebner: this cycle ;)
[00:06] <asac> so in lucid there is no choice bascially
[00:06] <micahg> asac: would I be allowed to blog about mozilla stuff for lucid if I make a blog?
[00:06] <asac> micahg: yeah. i dont know whats going on then ;) last user also says it doesnt helop
[00:07] <asac> so most likely some other extension causing this
[00:07] <asac> maybe with some odd side effect wrt ubufox
[00:07] <asac> micahg: everyone can blog about everything ;)
[00:07] <micahg> asac: that's what I figured, had another user blame ubufox when it was firebug 1.4
[00:07] <asac> we are in a free-speech world
[00:07] <asac> as long as you speak for yourself
[00:07] <asac> if you want to speak for mozillateam maybe check with me and fta
[00:07] <asac> on the text before publishing
[00:07] <asac> (to be nice)
[00:08] <micahg> asac: ok, that's what I wanted to know
[00:08] <asac> just apply some common sense
[00:08] <asac> if there are things you are sure are the mozillateam opinioon you can probably go ahead without checking
[00:08] <sebner> asac: haha, that means only 5 months left :P
[00:08] <asac> but i think its nice to let us know up front ;)
[00:08] <asac> sebner: for karmic there will be no change
[00:08] <asac> at least its not planned
[00:09] <asac> we will bring up a ppa when we upload to real archive though
[00:09] <asac> (hopefully)
[00:09] <micahg> well, I figure with stuff like TB3 and everyone asking questions with no answers anywhere, it seemed like a blog would be a good idea
[00:09] <asac> yeah definitily
[00:09] <asac> you are member=?
[00:09] <asac> then you can add yourself to planet ubuntu
[00:09] <micahg> asac: yep :), I just need to lock down a wordpress instance on my server
[00:09] <asac> or use some hosted service
[00:10] <asac> personally i should have used a hosted service rather imo. but well. once the damage is done it doesnt matter much ;)
[00:10] <sebner> asac: PFFFFFFFFFFFFFFFFFFFFFf, who the hell talks aobut karmic. lucid plays the music, bleeding edge ftw! you know that is my motto ;D
[00:11] <asac> great
[00:11] <asac> then tbird will be there soon for you ;)
[00:11] <asac> no way to escape
[00:11] <asac> report bugs ;)
[00:11] <asac> this year should be the goal ;)
[00:11] <asac> at best before my holiday burn time
[00:11] <asac> that starts one week ago ;)
[00:11] <asac> hehe
[00:12] <asac> no i think i will go to burning holiday like mid next week
[00:12] <micahg> asac: bug 494941...
[00:12] <micahg> asac: my "feature" was a bug
[00:12] <asac> hmm
[00:12] <asac> what feature?
[00:12] <micahg> targeting upstream milestones on bugwatches
[00:12] <asac> ah  ;)
[00:12] <asac> cool
[00:13] <asac> that explains it
[00:13] <asac> do you know if bugs with upstream watches now get upstream mail too?
[00:13] <asac> e.g. if upstream comments does that get send to subscribers as well=
[00:13] <asac> ?
[00:13] <micahg> asac: yes, they do
[00:13] <asac> imo it hsould do that to allow users to react on questions
[00:13] <asac> cool
[00:13]  * asac should check bugmail ;)
[00:13] <micahg> but, bug 488536
[00:13] <asac> very good. so now we are at the stage where we can just verify bugs, forward and then let upstream work together with ubuntu users
[00:14] <asac> while we provide the dailies to verify
[00:14]  * asac happy 
[00:14] <asac> so new bug triage rule is to aggressively forward new bugs to the right upstrema compoennt
[00:14] <asac> and then let them deal with that
[00:14] <micahg> asac: users can reply to upstream by clicking a link in LP (the comment is fwded upstream AFAIK, but I havent' tested
[00:15] <asac> yeah
[00:15] <asac> just wanted to check if they also get mails
[00:15] <asac> for upstream replies
[00:15] <sebner> asac: hahah, holidays, I remember 1-2 years ago when new ff appeared like now and you updated it mid january ^^
[00:15] <micahg> asac: I'm assuming we still try to verify/deuplicate?
[00:15] <asac> or if we have to hunt that down
[00:15] <asac> sebner: i dont think that ever happened
[00:15] <asac> sebner: we always had the latest and greatest
[00:15] <asac> in hardy even the beta5 ;)
[00:17] <asac> micahg: sure. we do initial verification. and then forward - checking for upstreams
[00:17] <asac> in theory we dont need to check for downstream dupes ;)
[00:17] <asac> though having two roads might help to better find dupes ;)
[00:17] <micahg> asac: there's a new dupefinder script
[00:18] <asac> for moz or launchpad?
[00:18] <micahg> asac: also, there's a new PPA bug policy
[00:18] <asac> from our qa team?
[00:18] <asac> hmm
[00:18] <asac> whats that policy?
[00:18] <micahg> asac: qa
[00:18] <asac> (in short words)
[00:18] <micahg> our
[00:18] <micahg> PPA bugs can be filed against packages and get tagged PPA
[00:19] <asac> cool
[00:19] <asac> thats good news
[00:19] <micahg> but it's supposed to be limited
[00:19] <asac> will they appear under /ubunt7 ?
[00:19] <asac> liminted in what way?
[00:19]  * micahg is looking for the email
[00:22] <av`> asac, what's your suggestion to have all the folders watched for new emails?
[00:23] <av`> asac, I mean, how can I see a specific folder received a mail
[00:23] <av`> asac, since it says new messages arrived just for the INBOX folder actually
[00:24] <asac> ask me tomorrow ;)
[00:24] <asac> have to look in my muttrc
[00:25] <asac> i think its the "mailboxes = ..."
[00:25] <asac> thing
[00:25] <asac> (out of my head)
[00:25] <asac> check the muttrc or something
[00:25] <asac> there is an example i am sure
[00:30] <av`> asac, yup, works now
[00:30] <av`> added mailboxes thing
[00:30] <asac> kk
[00:31] <asac> my brain still works it seems ;)
[00:32] <micahg> asac: here's the basic premise: https://lists.launchpad.net/ubuntu-bugcontrol/msg00496.html
[00:33] <sebner> asac: jajaajaa, wer's glaubt :P
[00:34] <asac> sebner: show me when that happened
[00:34] <asac> really. my track record is flawless ;)
[00:35] <asac> at least for stable distributions i am sure
[00:35] <asac> maybe 3.5 wasnt rolled on first day ;)
[00:35] <asac> to karmic
[00:35] <av`> asac, yup, looks like that running imapfilter and mutt on the same pc it's not the best, got some segmentation faults when they were running together
[00:35] <asac> (develpoment)
[00:35] <asac> not sure
[00:35] <av`> asac, gonna move imapfilter to my server
[00:35] <asac> never used imap filter
[00:35] <asac> server side filtering feels better
[00:35] <av`> yep
[00:36] <asac> i use procmail
[00:36] <asac> then export with some imap i cant remember ;)
[00:36] <asac> and then use offlineimap to sync to mdirs on each system i am using
[00:36] <micahg> hi hggdh, do you know where the wiki page is for the new PPA policy?
[00:36] <micahg> *bug policy
[00:49] <av`> asac, and tomorrow it's irssi time
[00:49] <av`> :)
[00:49] <av`> going to sleep now
[00:49] <av`> have a great night
[00:53] <sebner> asac: hmm, it was a stable release update for ff 3.0 iirc. I don't say bullshit just to annoy you ;)
[00:55] <asac> the only delay was for ffox 3.0
[00:55] <asac> we had to do a beta to final transition with string changes
[00:55] <asac> and at the day they released 3.0 final i was on my way to prague UDS ;)
[00:56] <asac> so it got out 10 days afterwards
[00:56] <asac> yes
[01:15] <sebner> asac: UDS are never in December so I'd say no
[01:17] <asac> well
[01:17] <asac> whatver;)
[01:17] <asac> show it to me ;)
[01:30] <sebner> pfff
[01:32] <sebner> asac: what FF stable release update appeared in December 07? Might be a FF2.0 thing
[01:34] <asac> 2.0.0.11+2nobinonly-0ubuntu0.7.10
[01:36] <asac> http://www.mozilla.org/security/known-vulnerabilities/firefox20.html
[01:36] <asac> http://www.mozilla.com/en-US/firefox/2.0.0.11/releasenotes/
[01:36] <asac> 30th nov
[01:37] <asac> dec 4 is ok i guess ;)
[01:37] <asac> most likely a friday release
[01:37] <asac> which we dont do
[01:37] <asac> because noone can react on regressions
[01:39] <sebner> asac: grr, I'll find the specific stuff and if that's the last thing I'll do in my life *muahahahaha*
[01:39] <asac> hahahaha
[01:39] <asac> have fun ;)
[01:39] <asac> flawless history as i said ;)
[01:39] <asac> :-P
[01:39] <asac> anyway. good night.
[01:39] <fta> google-chrome-unstable           20255   1.48%      4923    9482    5831      19
[01:39] <fta> google-chrome-beta                1174   0.09%       100       4    1069       1
[01:39] <asac> otherwise future will be doomish
[01:40] <fta> chromium-browser                 24511   1.79%      4522   12500    7484       5
[01:41] <asac> well. popcon is not really a good reflection of the current usage imo. nobody knows whats going on there ;)
[01:41] <fta> but that's all we have :(
[01:41] <asac> yeah
[01:41] <asac> lets work on spy ware ;)
[01:41] <asac> probably a good selling point ;)
[01:41] <sebner> asac: gn8. /me goes too though I'm ditching university tomorrow :P
[01:42] <asac> dont ditch university ;)
[01:42] <asac> no ... ditch it and learn at home instead ;)
[01:42] <asac> usually is more productive
[01:42] <sebner> that's partially my plan yes
[01:42] <asac> than goin there and then learning at home on top ;)
[01:42] <asac> only prob is that you need to have a good work attitude ;)(
[01:42] <asac> otherwise all is lost
[01:42] <sebner> and I don't want to get up early and travelling all in all 1 hour for a 45 min lesson
[01:43] <asac> and you end up learning everything at the last two days before exams ;)
[01:43] <sebner> heh
[01:43] <asac> thats how it starts...
[01:43] <asac> get up early ... travel there. dont go in session, but learn in front of it ;)
[01:43]  * sebner has the suspicion asac knows about the stuff he speaks :P
[01:43] <asac> not really ;)
[01:44] <sebner> heh
[01:44] <asac> i just know what can happen
[01:44] <sebner> don't worry, I'm not that kind of person where this happens. I still participate in at least 90% of the lessons where some of my friends visit ~10%
[01:45] <asac> hehe
[01:46] <asac> like other problemns ... you dont see it until its too late ;)
[01:46] <asac> anyway off ;)
[01:48] <sebner> heh
[01:48] <sebner> yeah gn8
[12:07] <asac> [reed]: http://people.canonical.com/~scott/daily-bootcharts/ ... does not display images in firefox
[12:08] <asac> but in chromium it works
[12:08] <asac> i think its svg with <img tags
[12:10] <[reed]> indeed
[12:10] <[reed]> that's also why images are broken
[12:10] <[reed]> for mime-types
[12:10] <[reed]> of .svg themes
[12:11] <fta> yep, ff sucks with svg, can't do anything with them beside displaying them alone
[12:11] <fta> i gave up on ff for my svg devs
[12:20] <fta> asac, ^^, it's also possible to trick it by moving to xhtml
[12:20] <fta> but it's just ugly, whatever you try
[12:26] <asac> fta: so you say using xhtml will cure that bootchart page?
[12:30] <fta> asac, http://wiki.svg.org/SVG_and_HTML
[12:31] <fta> you'll quickly realize it's a mess
[12:51] <asac> hmm
[12:51] <asac> are there moz bugs for that?
[12:51] <asac> [reed]: do you know?
[13:01] <fta> asac, some users keep asking me to enable webgl in chromium, i thought i did, but apparently, google enabled it only in the their dev channel: http://code.google.com/p/chromium/issues/detail?id=21852#c9
[13:02] <fta> so the question is should i add it too?
[13:03] <asac> fta: right. so maybe instead of real dailies, track the dev channel for now
[13:04] <fta> nm, it's both in trunk and in the beta
[13:04] <fta> but it doesn't work
[13:05] <fta> BUGabundo_work, hey
[13:05] <fta> BUGabundo_work, did you test the beta?
[13:05] <BUGabundo_work> ola fta
[13:05] <BUGabundo_work> whats up ?
[13:10] <fta> BUGabundo_work, ^^
[13:11] <asac> BUGabundo_work: beta beta beta test
[13:13] <asac> fta: /usr/bin/make  -C build-tree/mozilla  -j0
[13:13] <asac> is that -j something we add ?
[13:13] <asac> http://launchpadlibrarian.net/36672307/buildlog_ubuntu-lucid-armel.xulrunner-1.9.2_1.9.2~b6~hg20091210r33346%2Bnobinonly-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz
[13:13] <asac> e.g. guessing processor count?
[13:13] <fta> yep, i did
[13:13] <asac> we have to check to use at least 1 ;)
[13:14] <fta> i have a test for 1, let me see
[13:14] <asac> yep
[13:14] <fta> PROCESSORS := $(shell grep -c ^processor /proc/cpuinfo)
[13:14] <fta> ifneq (1,$(PROCESSORS))
[13:14] <fta> DEB_MAKE_EXTRA_ARGS += -j$(PROCESSORS)
[13:14] <fta> ok, 0 != 1 :(
[13:15] <fta> grep -ic should work
[13:15] <asac> shouldnt we use PROCESSORS + 1 ...?
[13:15] <asac> so if its 0 we still have 1 ;)
[13:15] <fta> iirc, your cpuinfo was weird. could you try grep -ic ^processor /proc/cpuinfo ?
[13:16] <asac> that works
[13:16] <asac> but seems not to work on builders
[13:16] <asac> adding a safety net would be great
[13:16] <asac> http://paste.ubuntu.com/339204/
[13:16] <fta> Initiating build 1390038-2870504 with 0 processor cores.
[13:16] <asac> yes
[13:16] <fta> even sbuild is confused
[13:17] <asac> just add a safety net
[13:17] <asac> i am not sure whats going on ... maybe /proc is not fully there
[13:17] <asac> or something
[13:21] <BUGabundo_work> $ grep -c ^processor /proc/cpuinfo 2
[13:22] <asac> nice ;)
[13:22] <asac> strong system
[13:22] <asac> :)
[13:22] <asac> normal system though in x86 world nowadays
[13:23] <BUGabundo_work> work PC
[13:23] <BUGabundo_work> del optiplex 755
[13:23] <BUGabundo_work> 8GB RAM
[13:23] <BUGabundo_work> C2D
[13:23] <BUGabundo_work> model name	: Intel(R) Core(TM)2 Duo CPU     E6550  @ 2.33GHz
[13:23] <BUGabundo_work> cpu MHz		: 2327.748 cache size	: 4096 KB
[13:24] <fta> asac, http://paste.ubuntu.com/339209/
[13:25] <BUGabundo_work> fta: anything you need test for beta?
[13:25] <asac> fta: great. so we use PROCESSOR for -j?
[13:25] <BUGabundo_work> should i start to ask users to run that repo?
[13:25] <BUGabundo_work> how many builds do you expect per time unit?
[13:25] <asac> err
[13:25] <asac> fta: why do you use different regexp
[13:25] <fta> BUGabundo_work, install it, use it and if you're happy, blog about it, spread the news
[13:25] <asac> in comment and above?
[13:25] <asac> hsouldnt we just use the same there?
[13:25] <BUGabundo_work> fta: u got an ARM ? kewl
[13:26] <BUGabundo_work> fta: using daily ppa already
[13:26] <asac> i will block once i verified that it works well
[13:26] <asac> blog
[13:26] <BUGabundo_work> 4.0.269.0 (Ubuntu build 34249)
[13:26] <BUGabundo_work> even on debian :D
[13:26] <asac> then you are ahead
[13:26] <asac> downgrade if you want beta
[13:26] <fta> BUGabundo_work, nope, i wish i did, i won't look dumb poking with fixed in the dark
[13:26] <asac> please verify that it works BUGabundo_work
[13:26] <fta> BUGabundo_work, read the ppa header, at least once
[13:26] <BUGabundo_work> okay
[13:27] <fta> -fixed+fixes
[13:27]  * BUGabundo_work reads https://edge.launchpad.net/~chromium-daily/+archive/beta
[13:27] <fta> asac, the regexp is to match your cpuinfo style
[13:27] <fta> asac, try it
[13:28] <BUGabundo_work> btw chromium-browser-inspector is broken
[13:28] <fta> so i can commit everywhere
[13:28] <BUGabundo_work> wont install
[13:28] <asac> one sec
[13:28] <fta> BUGabundo_work, you need to downgrade it too, same for -dbg if you have it
[13:28] <asac> fta: doesnt work on x86 ;)
[13:28] <asac> grep '^(model name|Processor)' /proc/cpuinfo | head -1
[13:28] <asac> nothing
[13:28] <fta> asac, oops add -E
[13:28] <asac> fta: egrep
[13:28] <asac> yeah
[13:29] <BUGabundo_work> fta: i wont be using beta :p
[13:29] <BUGabundo_work> daily is enough
[13:29] <BUGabundo_work> but i can get a group of testers
[13:29] <asac> fta: go for it
[13:29] <fta> i had it right here, but i missed it in bzr
[13:29] <asac> with -E
[13:29] <BUGabundo_work> *if* the builds arent very often
[13:29] <BUGabundo_work> ppl seem to get bored with daily updates
[13:29] <BUGabundo_work> go figure
[13:29] <asac> BUGabundo_work: we rely on users helping testing our stuff
[13:29] <BUGabundo_work> (if only they had 5 daily ppas with debug package like i do)
[13:29] <asac> and since you asked for beta explicitly ... please test the bits prepared for you at least ;)
[13:30] <BUGabundo_work> err
[13:30] <BUGabundo_work> i didnt ask it *for me* but for others
[13:30] <asac> ok
[13:30] <BUGabundo_work> who heard the news and wanted it
[13:30] <asac> still having you on the fore-front to test before we spread the news
[13:30] <asac> feels heroic ;)
[13:30] <fta> yep, test plz, then you can move back to trunk, i will too
[13:30] <BUGabundo_work> and daily is usual to more pron errors
[13:30] <asac> yes. still. we want to spread the news. and helping on testing is heroic ;)
[13:31] <asac> though volunarily ;)
[13:31] <BUGabundo_work> asac: ff 3.7 , ch, NM, pidign, gnome-do, nvidia, etc
[13:31] <BUGabundo_work> all trunk or daily
[13:31] <asac> sure
[13:31] <asac> doenst mean you can help testing stable bits ;)
[13:31] <asac> cant
[13:31] <BUGabundo_work> i run lucid and debian unstable
[13:31] <BUGabundo_work> i cant test stable bits LOL
[13:33] <fta> yes you can, tiny bits ;)
[13:35] <fta> asac, didn't we say that we could stop adding the " - update ..." in bzr commit logs?
[13:35]  * fta feels unsure
[13:36] <fta> bzr log -v already does that
[13:37] <asac> fta: no.
[13:38] <asac> fta: we said we dont want to add patch rebase stuff to changelog
[13:38] <asac> fr things that are under development
[13:38] <asac> still using the same comment in bzr commit
[13:38] <asac> like "rebase patch" -> dont put in changelog if its not a stable release update3
[13:39] <asac> fta: the webview doesnt do that etc.
[13:39] <asac> i think we can think about droppin git
[13:39] <asac> but afair we didnt change that so far
[13:39] <fta> it doesn't? you mean turtle?
[13:40] <asac> if you log at the log in launchpad
[13:40] <fta> or tortoise, or whatever the name of that slow & blotted thing it
[13:40] <fta> is
[13:40] <asac> there is no hint about what files are touched on top level
[13:40] <fta> oh, the lp extract, not the bzr viewer
[13:41] <asac> that for one
[13:41] <fta> *sigh* looks redundant to me
[13:42] <asac> as i said. we can review what we do
[13:42] <asac> but we didnt change it yet
[13:42] <asac> i think stuff added to changelog still should have that
[13:42] <asac> for stuff not in changelog i dont care
[13:42] <asac> if you say its better without, then go for it ;)
[13:42] <asac> but stuff committed with debcommit will include that info if we add it to changelog still
[13:43] <asac> so it might look inconsistent
[13:44]  * BUGabundo_work just got one more Ch beta tester
[13:44] <asac> coolio
[13:45]  * BUGabundo_work updates to latest flash 64bits
[13:46] <BUGabundo_work> darn we are never gonna get this packed :(
[13:46] <BUGabundo_work> gnomefreak: did you ever did manage to do any progress on it ?
[13:47] <fta> asac, all branches fixed
[13:48] <asac> great
[13:49] <gnomefreak> BUGabundo_work: on what?
[13:49] <gnomefreak> ah flash no i didnt but i also remembering someone say they were working on it
[13:55] <BUGabundo_work> fta: common question i get: whats the diff on Chromium and Chrome builds??
[13:55] <BUGabundo_work> i know you build them for all our supported releases
[13:56] <BUGabundo_work> and that googles one is binary for somethign like 8.04
[13:56] <BUGabundo_work> but nothing more then that
[13:57] <BUGabundo_work> [13:57] <IdleOne> Chrome is 1 second, Chromium 4-5 seconds to load
[13:59] <gnomefreak> 2.6.32-7-generic is not a package :(
[13:59] <fta> strange, did he try with an empty profile / cache for both?
[14:01] <fta> BUGabundo_work, at least, chromium doesn't have that http://en.wikipedia.org/wiki/Google_Chrome#Usage_tracking
[14:01] <fta> the RLZ and clientid part
[14:01] <fta> and who know what else chrome also adds
[14:01] <gnomefreak> ah its linux-image-2.6.32-7-generic
[14:02] <fta> it's not just a branded chromium with a shiny icon
[14:05] <BUGabundo_work> fta: [14:00] <IdleOne> I did not. will try
[14:06] <BUGabundo_work> lolol i never notice the icon, anyway
[14:07] <gnomefreak> :) i think it works. i will know in ~3 hours
[14:12]  * gnomefreak gone for a little bit
[14:19] <fta> BUGabundo_work, the build flags are the same, it use more system libs but google told me they will use the same as i do by default in the next version. so the only remaining difference is the toolchain. if it want to give it a try, install the same version of chromium from the ppa but try hardy vs karmic/lucid
[14:20] <fta> BUGabundo_work, if hardy is faster, we have a problem with our toolchain
[14:21] <BUGabundo_work> i have hardy here on debian
[14:21] <BUGabundo_work> and lucid at home
[14:21] <BUGabundo_work> dont notice any diff in speed
[14:24] <fta> no, you should compare in the same conditions, meaning same h/w, same kernel, same everything else
[14:24] <gnomefreak> there was a package in a ppa that enhanced websites made by google. dont recall name or what PPA it is in
[14:24] <fta> just change 1 variable at a time
[14:24] <BUGabundo_work> wont work on debian
[14:24] <BUGabundo_work> anything above hardy
[14:24] <BUGabundo_work> thats why i use it
[14:25] <fta> you don't understand. try at home on your lucid box, select the lucid ppa, install, clear the cache/profile, test, select the hardy ppa, downgrade, clear the cache/profile, test, then compare
[14:26] <gnomefreak> PPA supports lucid?
[14:26] <fta> sure
[14:27] <fta> BUGabundo_work, ^^, you can tell IdleOne to try that if you want to help
[14:28] <BUGabundo_work> fta: i did understand it
[14:29] <BUGabundo_work> i'm just to lazy to do all those tests
[14:29] <BUGabundo_work> :p
[14:29] <fta> asac, we should have something like that: http://build.chromium.org/buildbot/perf/dashboard/overview.html#Chromium-Linux
[14:30] <fta> maybe something slightly easier to read
[14:30] <asac> hmmm interesting
[14:30] <asac> can that be run on mozilla too?
[14:30] <asac> for comparison?
[14:30] <gnomefreak> fta: thanks trying them now
[14:31] <fta> asac, well, it's based on the chromium perf tools built with the unitests, but moz has an equivalent
[14:32] <fta> asac, http://build.chromium.org/buildbot/waterfall/builders/Linux%20Perf/builds/4400
[14:33] <asac> fta: can you uploa da new codecs snapshot?
[14:33] <asac> that should be fixed upstream now
[14:34] <fta> a fix landed in the last 12h?
[14:34] <asac> for chromium we sitll need those armv7 droppage and the skia.gyp change i suggested
[14:34] <asac> yes
[14:34] <asac> not sure when exactly
[14:34] <asac> guy pinged me this early morning
[14:34] <asac> 3am
[14:34] <asac> or 2
[14:34] <fta> well, if it's a fix in the gyp file, i don't yes it.. yet
[14:34] <fta> -yes+use
[14:35] <fta> (damn, i need more sleep)
[14:35] <BUGabundo_work> ahaha
[14:35] <BUGabundo_work> i sleep 6h / day
[14:36] <asac> fta: well. the code fix is there too in codecs now
[14:36] <asac> and we have to use fPIC for armel
[14:36] <asac> too
[14:36] <asac> it was done in gyp afaik
[14:36] <asac> or config
[14:36] <asac> not sure
[14:36] <asac> on i386 we must _not_ use fPIC i was told
[14:38] <fta> i should speed up the move to the sumo codec / gyp then..
[14:47] <fta> kenvandine, any chance to have the stream view fixed in gwibber? the close stream icon does nothing
[14:47] <kenvandine> really?
[14:47] <BUGabundo_work> fta: ctrl+w
[14:47]  * kenvandine checks
[14:47] <BUGabundo_work> kenvandine: havent worked for me in a *long* time the icon
[14:48] <fta> BUGabundo_work, that's a workaround, not a fix :)
[14:48] <BUGabundo_work> i know
[14:48] <BUGabundo_work> jsut trying to help
[14:48] <fta> yep, same here, it never worked in gwibber 2
[14:48]  * gnomefreak would love to close gwibber and it closes *-daemon
[14:48] <kenvandine> gnomefreak, it does... if you "quit"
[14:48] <fta> gnomefreak, it does that now
[14:49] <gnomefreak> fta: kenvandine thanks so use quit instead of "x"
[14:49] <kenvandine> the close button works for me...
[14:49] <kenvandine> for a stream that is
[14:49] <kenvandine> search stream right?
[14:50] <gnomefreak> yeah iirc. i havent opened gwibber in a while (3 weeks or so)
[14:50] <fta> kenvandine, try a user
[14:50] <kenvandine> yeah, the big X closes the stream for me
[14:50] <kenvandine> ok
[14:51] <BUGabundo_work> kenvandine: user doesnt
[14:51] <BUGabundo_work> never use searchs
[14:52] <gnomefreak> does clear * work now also? i cant run it for a while
[14:52] <gnomefreak> clear stream
[14:53] <kenvandine> the close button works for me in a user stream
[14:53] <kenvandine> oh... that little close X is next to the stream too
[14:53] <kenvandine> i thought ryan removed that until we can fix gtk to handle it
[14:54] <kenvandine> there is also a X at the top when you are viewing a stream
[14:54] <kenvandine> that one works
[14:54] <kenvandine> the one next to the user doesn't
[14:55] <fta> yes, the one next to the user name in the stream view pane
[14:55]  * kenvandine will remind ryan to remove that until we can make it work
[14:56] <kenvandine> it is a limitation of the gtk cell renderer
[14:56] <kenvandine> it is where he wants the close button to be... :)
[15:30] <ccheney> asac: ping
[15:41] <asac> ccheney: hola
[15:42] <asac> ccheney: could you please add which package references that?
[15:42] <asac> currently we cannot see if hte app is on xulrunner-1.9 or whatever
[15:43] <asac> then we start the transition ppa i guess
[15:43] <ccheney> just need the source package eg xulrunner xullrunner-1.9 or xulrunner-1.9.1 ?
[15:43] <asac> ccheney: well. xulrunner is redundant as the source in hardy is 1.8 and the binary is 1.9 or even 1.9.1 i think
[15:44] <ccheney> i'm confused, xulrunner in karmic appears to be 1.8.1.16 ?
[15:44] <asac> why are there things like openjdk-6
[15:44] <asac> where there is no binary package?
[15:45] <asac> ccheney: ok. then xulrunner, xulrunner-1.9, xulrunner-1.9.1 is enough
[15:45] <ccheney> the source of openjdk-6 depends on a xulrunner package, all packages without binaries are like that
[15:45] <ccheney> eg openoffice.org
[15:46] <asac> ccheney: right. so check for them which of the binary packages actually uses it
[15:46] <asac> like for openjdk-6 the plugin package
[15:46] <asac> for openoffice also the plugin package
[15:46] <asac> might need manual digging
[15:47] <ccheney> none of them use it at runtime, just a build-dep, do you mean track down inside the source which part of the source uses it?
[15:52] <asac> ccheney: yes. the plugins use it at runtime imo
[15:52] <asac> they just dont run on their own
[15:52] <asac> i think most htat dont have depends in binaries are plugins
[15:52] <asac> but worth checking
[15:52] <asac> might also be just a bad package with missing depends
[15:56] <ccheney> ok
[20:34] <ripps> whoa, i just noticed that chromium-daily's scrollbar now matches theme colors. Been a long time coming
[20:39] <fta> i like that it also shows all matches when doing a search
[20:42] <fta> asac, gyp_0.1~svn767-0ubuntu1_all.deb
[20:42] <fta> asac, so now, i can fight against the ffmpeg sumo
[21:10] <ccheney> asac: updated to reflect source package it depends against
[21:17] <ccheney> asac: when we update the firefox in the old releases we don't want anything using the old versions of xulrunner at all, is that correct?