[00:27] <fta> [reed], would it be possible to have revids somewhere in http://hg.mozilla.org/mozilla-central/pushlog ?
[00:27] <fta> in addition to those ugly changesets
[00:41] <fta> asac, 1st round, https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
[00:42] <fta> asac, i just started my improved bot with just xul/ff 3.2, daily for now
[00:43] <fta> this is for hardy->jaunty
[02:17] <[reed]> fta: does http://hg.mozilla.org/mozilla-central/pushloghtml have what you need?
[02:17] <[reed]> oh, that's not a feed
[02:18] <fta> i don't really need a feed
[02:19] <fta> i need a way to get the revid of the tip with the date
[02:19] <fta> preferably in a unique timezone, unlike what is available today
[02:19] <fta> the xml feed is fine for the date but lack the rev id
[02:20] <[reed]> file a bug under mozilla.org :: Hg Customizations
[07:15] <wikz> https://bugzilla.mozilla.org/show_bug.cgi?id=449691
[08:04] <asac> fta: yeah. when i wanted to commit it the tree was frozen
[08:09] <asac> fta: so how much mem do we need ffor the daily ppa?
[08:19] <mpt> rheet
[08:31] <fta> hi
[08:32] <fta> asac, depends, what for? the ppa size, or archives?
[08:32] <fta> https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
[08:32] <asac> fta: 20:22 < toddw> asac: for the Python, Komodo requires a shared Python build (which should  be okay as system Python)
[08:33] <asac> 20:23 < toddw> asac: then the build scripts "build.py" would need to be tweaked to  override the siloedPython setup
[08:33] <fta> just xul + ff = 1G already
[08:33] <asac> i guess that doesnt really help though
[08:33] <asac> fta: yeah. so what size should we ask for to get started?
[08:33] <asac> 20?
[08:35] <fta> depends of what we want to put in there
[08:37] <asac> 50?
[08:40] <fta> lol, 20 is enough, as there's only two versions of each binary at any given time (and only 1 once the superseded ones are removed)
[08:42] <asac> fta: really? ... ok. thought we would at least have  abit of history
[08:42] <fta> we want to but that's not how the ppa quota is working, afaik
[08:43] <fta> archives in librarian is a different thing
[08:43] <fta> this is 30 days max of superseded binaries
[08:43] <fta> disregarding the size
[08:44] <fta> if we want more, we need to backup those ourselves, or request an exception
[08:46] <asac> yeah
[08:47] <asac> so you say the superseeded bits are not in the quota
[08:47] <asac> ?
[08:47] <fta> i think so
[08:48] <fta> but maybe i'm wrong
[08:48] <asac> ok. i will tell mrevell that we want 20
[09:09] <fta> Bug 316773 :(
[09:20] <asac> what bug is that=?
[09:20] <asac> i mean ... how did you get it?
[09:20] <fta> i filed it
[09:20] <asac> fta: i think we should also do comm-central nighlies
[09:20] <asac> fta: why did you mark it private?
[09:21] <fta> security
[09:21] <fta> it was about branch whiteboards editable by anyone
[09:21] <fta> it's Won't Fix now
[09:21] <asac> thats not security ;) ... really
[09:21] <asac> open it up
[09:21] <asac> at least its not severe enough to hide it ;)
[09:22] <fta> bug 316773
[09:22] <fta> still security but visible now
[09:23] <asac> yeah
[09:23] <asac> thx
[09:24] <asac> hmm ... i think both side have valid arguments
[09:24] <asac> imo everybody should be able to add stuff to whiteboard
[09:24] <asac> but not overwrite old things
[09:26] <asac> fta: i think we want dailies for tbird 3 and ffox 3.1 too
[09:26] <asac> that should be enough i guess
[09:26] <asac> otoh ... having 3.0 too would be nice
[09:29] <fta> if i'm upstream, i don't want anyone not in the team touching to the whiteboards
[09:33] <fta> for the dailies, yes, sure, i just want to be sure my bot won't do nasty things
[09:33] <asac> fta: cool
[09:33] <asac> fta: ok commented on bug
[09:34] <asac> fta: imo if they dont reconsider wont fix we should open a bug that allows branch owners to disable whiteboard
[09:49] <fta> asac, at what time do we want the bot to run? midnight? noon?
[09:49] <fta> 4am?
[09:53] <asac> fta: yeah 4am is a good time i think ;) ... so we have an update every morning ;)
[09:53] <asac> for breakfast
[09:54] <fta> remember i don't test build, it also means FTBFS for breakfast
[10:06] <mconnor> mpt: so, if you're not at FOSDEM, will you be back in London next week?
[10:06] <mconnor> we could discuss this in front of a whiteboard, or over pints, or both :)
[10:10] <mpt> Hi mconnor, I don't think I'll be going to Fosdem, but yes I will be in London next week
[10:10] <mpt> Would be good to meet you and discuss this more
[10:12] <mconnor> mpt: where is Canonical, anyway?  I have an appt in Soho Monday morning, and theoretically flying home Wednesday, but that's all up in the air
[10:12] <mpt> mconnor, Millbank Tower, just south of Westminster
[10:14] <mconnor> hmm
[10:14] <mconnor> I just realized I have no idea how far apart those are!
[10:15] <mpt> How far apart they are depends on whether it's snowing ;-)
[10:15] <mconnor> haha
[10:16] <mconnor> I'm Canadian, I'm used to snow
[10:16] <mconnor> also, isn't that the point of, y'know, a subway system?
[10:16] <mpt> No, it isn't <http://severe-delays.livejournal.com/67893.html>
[10:17] <mpt> (summary: if subway drivers can't get to the station, there's no-one to drive the trains)
[10:17] <mconnor> haha
[10:17] <mconnor> rock
[10:18] <mpt> With buses running, though, Soho Square to Millbank Tower takes about 40 minutes
[10:18] <mconnor> hmm, that's entirely doable
[10:20] <mconnor> what about to LHR from there?
[10:20] <mconnor> I was kinda thinking I'd take the Monday night flight home instead, if I can make that workable and still get stuff done :)
[10:23] <mpt> Depends on your budget. 1h20m to Terminal 1/2/3 if you're ok with shelling out £16.50 for the Heathrow Express. 1h30m with £6.90 for the Heathrow Connect.
[10:24] <mpt> (Either way, add about 5 minutes for Terminal 4 or 5.)
[10:25] <mconnor> ten pounds to save ten minutes seems excessive, wow
[10:25] <mconnor> I guess location matters
[10:26] <mconnor> mpt: dare I ask what an airport car costs?
[10:27] <mconnor> since driving is apparently 34 minutes with traffic
[10:27] <mpt> That I don't know, sorry, your googling would be as good as mine
[10:28] <mconnor> hmm
[10:28] <mconnor> 37 pounds
[10:29] <mconnor> that seems reasonable-ish to save an hour, given what I'm spending already to be in London...
[10:30] <mconnor> or I can just fly home Tuesday and spend Monday night in a nice pub :)
[11:14] <asac> good to see that you two are going to discuss this. Thanks!
[12:19] <gnomefreak> :(
[13:08] <gnomefreak> anyone have a clue as to where i can change where the quoted text is in TB. I want my message to be above quoted text but cant seem to find the setting
[14:44] <gnomefreak> asac: fta anyway to generate upstream tarball using the version in debian/changelog?
[14:45] <asac> gnomefreak: just use the date term there
[14:45] <asac> and use DEBIAN_DATE=xxxxxxxxtyyyyyy
[14:45] <fta> depends if it comes from a tag or not
[14:46] <gnomefreak> http://pastebin.mozilla.org/616311 using from what #bzr told me to try
[14:47] <gnomefreak> seamonkey-2.0: remote site does not even have current version  << bothers me the most from the error
[14:52] <fta> debian/rules get-orig-source DEBIAN_DATE=20090201r1815
[14:53] <gnomefreak> thanks trying now
[15:01] <gnomefreak> i thought DD used =20090301txxxx
[15:01] <gnomefreak> but r is working fine it looks
[15:01] <fta> it does, but from cvs only, for all other vcs that has a concept of revision id, it's 'r' (revision) instead of 't' (time)
[15:02] <fta> -from+for
[15:02] <fta> have
[15:05] <gnomefreak> ah thanks i saved it in my file for commands and friends
[15:35] <asac> fta: may i upload latest 3.1.head?
[15:36] <asac> or do you want to do that?
[15:36] <fta> I can do it but it's a snapshot
[15:36] <asac> fta: just do  ... i mean the b3 will be out soon
[15:36] <asac> and we can bump again then
[15:36] <fta> ok
[15:36] <asac> its just that i need unversioned .pc files so seb can esily test ephy
[15:36] <asac> thanks
[15:38] <saivann> asac : ping
[15:38] <asac> saivann: png
[15:39] <saivann> asac : I'm about to have lightning-extension-locales and sunbird-locales ready for jaunty (in around 1 hour). I'll subscribe you to bug 324635 so you can review the packages.
[15:39] <asac> saivann: ok thanks. also add info what you did for testing
[15:40] <asac> fta: oh ... is .head already psat b3?
[15:40] <saivann> asac : I will do, thanks :)
[15:40] <asac> or still b3 pre?
[15:40]  * asac wonders whether they did a mini branch on 1.9.1 branch for b3
[15:40] <fta> i don't think so
[15:40] <asac> ok
[15:40] <asac> then all fine
[15:40] <asac> fta: just push the stuff  ... and tell me when you hvae closed -devscripts
[15:42] <fta> will do
[15:42] <fta> i'm sick of fighting with gvfs: gnome bug 570659
[15:50] <asac> hmm
[16:15] <asac> @time
[16:36] <fta> asac, can we push m-d now? i mean, with the freeze going on
[16:38] <saivann> asac : the locales are ready for your review : https://bugs.launchpad.net/ubuntu/+source/sunbird-locales/+bug/324635
[16:38] <asac> fta: oh ... good point ;)
[16:38] <asac> fta: its not on CD though
[16:38] <asac> fta: if its closed i will push it together with sec update to jaunty
[16:38] <asac> either tonight or tomorr morning
[16:41] <fta> asac, ok, what do you need, just the branch or a diff.gz/dsc
[16:47] <asac> fta: ok its open
[16:47] <asac> fta: i just need moz-devscript branch with closed changelog on top
[16:48] <fta> Pushed up to revision 195.
[16:49] <asac> ok updating from lp:mozillateam/mozilla-devscripts/mozilla-devscripts
[16:49] <fta> ~mozillateam/mozilla-devscripts/mozilla-devscripts/
[16:49] <fta> yep
[16:50] <fta> oh, in xul 1.9.1, i have -testsuite* now.. it means 2 NEW bin
[16:52] <fta> asac, too bad the testsuite package is not fully operational
[16:52] <asac> fta: what is Carp?
[16:52] <fta> in perl?
[16:52] <asac> fta: thats not a problem
[16:53] <asac> fta: just push now
[16:53] <asac> i have all the folks around here to push that through
[16:53] <asac> fta: yes
[16:53] <asac> fta: maybe check that we really have removed the versions from the .pc files on 1.9.1
[16:54] <fta> Carp is a module providing carp/cluck/croak/confess, ~ equiv of warn/die for classes/objects
[16:54] <asac> hmm
[16:54] <asac> ok
[16:54] <asac> not sure what that is  though ;)
[16:54] <asac> sounds cryptic ;)
[16:55] <fta> it reports errors from perspective of the caller
[16:55] <fta> and even provides a stack trace
[16:56] <fta> man Carp (if you have perl-doc installed)
[16:56] <asac> ok ;)
[16:56] <asac> i think the info you gave is enough ;)
[16:58] <asac> fta: done
[16:58] <fta> with warn and die, you see the file/lineno of that particular line, you sometimes want to expose the caller instead, or a full stack
[16:58] <fta> thanks
[17:00] <asac> fta: two weeks until feature freeze
[17:00] <asac> 10 days even
[17:00] <asac> hmm ... two weeks ;)
[17:00] <asac> :-P
[17:01] <asac> ok trying uxa now
[17:01] <asac> for intel cards
[17:01] <asac> (new accellmethod)
[17:07] <fta> asac, 1.9.1~b3~hg20090117r22878 not the freshest but it will do
[17:10] <fta> pushing the huge xul...
[17:11] <fta> i should update prism too. it's damn old :(
[20:54] <fta> asac, xul 1.9.1 is still b3pre upstream
[20:58] <asac> fta: fine
[20:58] <asac> i think its safe to deliver that to jaunty then ;)
[21:00] <fta> i pushed the one that was in my ppa
[21:01] <asac> good
[21:01] <asac> fta: did you also push ffox or just xul?
[21:02] <fta> both
[21:02] <fta> otherwise, gre would have failed
[21:02] <fta> b2 vs b3pre
[21:02] <asac> yeah
[21:02] <asac> ok
[21:08] <fta> it's nice to push those tarballs in 1sec :)
[21:08] <asac> 100Mbit?
[21:09] <fta> yes
[21:10] <fta> Estimated archive size: 777.9 MiB
[21:10] <fta> strange, it was 990M this morning
[21:10] <fta> and nothing should have been removed
[21:11] <fta> asac, https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa  step 2, ff3.1
[21:21] <asac> fta: thats great
[21:22] <asac> so ... tbird 3?
[21:22] <asac> not sure if we should also do 1.9/3.0 xul/ffox
[21:22] <fta> not today
[21:30] <asac> heh
[21:30] <asac> no need to
[21:32] <fta> http://www.sofaraway.org/ubuntu/tmp/bug-lp-ppa.png
[21:33] <asac> fta: yeah. rendering issueß
[21:33] <asac> i dont see it here
[21:34] <asac> fta: did we drop symbolic-functsions yet?
[21:34] <asac> from 3.1?
[21:35] <fta> i don't remember, my day was looooong and i'm falling asleep
[21:36] <fta> asac, http://paste.ubuntu.com/114188/
[21:37] <fta> that's how the conf of my (~new) bot looks like
[21:37] <asac> fta: hmm ... i dont have a release on the .head branch yet
[21:37] <asac> xul 1.9.1
[21:38] <fta> eh?
[21:38] <asac> its still unreleased
[21:38] <asac> Tree is up to date at revision 416.
[21:38] <fta> oops, pushed; i thought i did it
[21:38] <fta> done
[21:38] <fta> 417
[21:39] <asac> thy
[21:39] <fta> Using saved push location: bzr+ssh://fta@bazaar.launchpad.net/~mozillateam/firefox/firefox-3.1.head/
[21:39] <fta> bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
[21:39] <fta> ??
[21:40] <fta> oh damn, my fault
[21:41] <fta> don't pull 3.1 just yet
[21:46] <asac> fta: you bzr bind ;)
[21:46] <asac> err use i ment
[21:46] <asac> not you
[21:49] <fta> ok, #393
[21:49] <fta> i didn't overwrite
[21:49] <fta> we'll see if my bot will survive to this
[21:51] <asac> so you merged?
[21:52] <fta> yes
[21:53] <fta> i worked in the bot, i should not do that
[21:54] <fta> the problem of not bumping *.head daily is that xul and ff will now diverge regarding their versions, when we have something to fix in one but not in the other
[21:55] <fta> btw, i have a bunch of *.daily* branches now, i will push them in the ~umd
[21:55] <asac> fta: what purpose do they have?
[21:55] <fta> just showing history
[21:56] <asac> ok ... as long as we dont merge from there
[21:56] <asac> so when we change .head those probably need to be overwritten or force-merged or sometjing
[21:56] <fta> we should never touch them
[21:57] <asac> yes of course
[21:57] <asac> so are we resetting them when .head gets a new commit?
[21:58] <fta> no, the bot just merges and resolve conflicts in d/changelog (and d/control because i tweak versions in there)
[21:58] <fta> +s
[22:02] <fta> asac, you will have the pleasure to fix the diverged patches every morning ;)
[22:03] <fta> hopefully not *every* morning
[22:04] <fta> that will boost the motivation to get the patches upstreamed :P
[22:05] <asac> fta: yeah
[22:06] <asac> fta: one thing would habve been to forward the python stuff
[22:06] <asac> ;)
[22:06] <asac> before pushing to .head ;)
[22:06] <fta> ^upstreamed^committed ;)
[22:06] <fta> (csh syntax)
[22:07] <asac> hehe
[22:07] <asac> fta: latest 3.1 seems to have better fonts
[22:07] <asac> they look quite great here for me
[22:09] <fta> dtchen, my mplayer lost sound after I unpaused it
[22:09] <fta> E: alsa-util.c: snd_pcm_avail_update() returned a value that is exceptionally large: 3221224932 bytes (18260912 ms) Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers.
[22:09] <fta> E: module-alsa-sink.c: snd_pcm_mmap_commit: Device or resource busy
[22:09] <fta> dtchen, ^^
[22:09] <dtchen> fta: yes, i have local changes that address it
[22:10] <asac> dtchen: new nick?
[22:10] <dtchen> they didn't make it into the latest PA upload, but i can push to my ppa
[22:10] <dtchen> asac: "new" old
[22:10] <asac> i liked crimusn ;)
[22:10] <asac> err ... flipflip
[22:10] <fta> me too :)
[22:11] <dtchen> fta: uploaded, queued, etc.
[22:11] <fta> ok, thanks. I'll try tomorrow.
[22:11] <dtchen> upstream git HEAD fixes quite a few of these issues, but the changes are very invasive
[22:12] <dtchen> soname bump, too
[22:12] <fta> jaunty is a dev version, isn't what dev versions are for?
[22:14] <asac> 12 days till feature freeze ;)
[22:15] <fta> is that better to ship jaunty with crappy sound?
[22:16] <asac> i think we have a plan for that ;)
[22:16] <asac> we will blacklist a bunch of things
[22:16] <asac> for glitch free
[22:16] <asac> at least thatsa what came out of the sprint
[22:17] <asac> dtchen: is glitch free really the main issue we havehere?
[22:24] <dtchen> asac: it's one of them
[22:24] <dtchen> asac: there are a number of issues in the audio stack
[22:24] <dtchen> reaches all the way down from broken hw (e.g., HDA codecs) to how PA is configured by default to GUI apps to manipulate PA
[22:25] <asac> hmm
[22:26] <asac> http://identi.ca/notice/2111687
[22:26] <asac> so blacklist glitch free + use alsa mixer is curreent way to move forward
[22:29]  * dtchen contemplates how to wrangle it
[22:30] <dtchen> so, patch PA to check hal before enabling tsched?
[22:30] <dtchen> that's gonna be a sick patch
[22:31] <dtchen> otherwise, we could revert to using alsa completely by setting tsched=0 for everyone
[22:32] <dtchen> glitch-free does tend to act more sensibly once the watermark has been set high enough; otherwise, with tsched=0, PA just uses alsa's interrupt-based scheme
[22:34] <asac> dtchen: isnt glicht free about finding a perfect buffer size?
[22:35] <asac> dtchen: (besides other things)
[22:35] <dtchen> yes
[22:35] <asac> wouldnt it be possible to ust use a big cache?
[22:35] <asac> from what i understood the problem is supposed to be that some drivers give a bad value for that cache heurisitc
[22:36] <dtchen> yes, and you can approach it from either the driver or from PA
[22:38] <asac> right. but from my experiences with drivers, they take ages to get fixed ... if not forever
[22:38] <asac> so we need some kind of workaround for now
[22:39] <dtchen> sadly, there's no uninvasive workaround that will work for everyone
[22:39] <asac> at least for wifi i am waiting and waiting ... and while there are improvements they always get about the same mount of regressions
[22:40] <dtchen> if the tsched=0 was decided for all chipsets, that's a simple one-line change in etc/pulse/default.pa.in
[22:40] <dtchen> err, src/daemon/default.pa.in
[22:40] <dtchen> if it's to be selective, well, that's going to be a weekend hackfest
[22:41] <asac> but wouldnt tsched cause stuttering on a bunch of chips?
[22:41] <asac> tsched=0 i mean
[22:42] <asac> cool ... new hal is there ... i can finally boot my 2.6.29 rc3 kernel again
[22:42]  * asac reboots
[22:42] <dtchen> right now it causes stuttering on just about all hw depending on the user's workload
[22:42] <dtchen> the stuttering is most noticeable immediately after the pulseaudio daemon has been invoked
[22:43] <dtchen> at that point, the buffering hasn't settled
[22:43] <dtchen> at some point (normally within a few seconds), it has settled