[09:59]  * asac  reboots to new kernel
[10:20] <asac_> that didnt work out :/
[11:39] <asac> fta2: ok so test_handlerService.js seems to fail if gconf is not available ... so screen/chroot  etc.
[11:39] <asac> hmm
[11:40] <asac> so the gconfd needs to be started most likely
[12:23] <fta2> asac, you are referring to -testsuite, right?
[12:26] <asac> fta2: to make check in general
[12:26] <asac> for me the OS handler stuff fails when running that in a screen
[12:27] <fta2> file a bug and fix it :)
[12:28] <asac> not really fixable i think
[12:28] <asac> unless i know how to start gconf in screen
[12:29] <fta2> ask seb, he should have plenty of packages doing just that at build time
[12:29] <asac> gconf testing?
[12:46] <wikz> http://alioth.debian.org/docman/view.php/30046/2/menu-one-file.html#s3.7
[13:21] <asac> js> Components.classes["@mozilla.org/browser/shell-service;1"].getService(Components.interfaces.nsIShellService).desktopBackgroundColor = 0xFFEEAA;
[13:21] <asac> GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details -  1: Not running within active session)
[13:36] <asac> so seems its orbit
[13:37] <asac> what the hell is orbit? there is no server? i dont see a binary
[13:40] <asac> welcome sunilmohan ;)
[13:41] <sunilmohan> asac: hi :)
[13:42] <sunilmohan> I am helping wikz with Spicebird packaging
[13:42] <sunilmohan> I saw a patch with unix/packages-static file
[13:42] <asac> yeah ... now that i read your name careful i figure that
[13:43] <asac> sunilmohan: that patch isnt wanted upstream afaik. fta2 did it for tbird (if you refer to tbird patch)
[13:43] <sunilmohan> actually I was also worried about it.
[13:44] <sunilmohan> windows/packages-static and installer/Makefile.in (list of files to exclude) are pain to maintain
[13:45] <sunilmohan> many times we forgot something or the other in these two files and removed-files and had major problems
[13:45] <sunilmohan> unix/packages-static looks like another problem if we have to maintain it
[13:46] <sunilmohan> I think some who reusing the exclusion list from installer/Makefile is a better idea.
[13:47] <sunilmohan> so for now asking wikz not to prepare a similar patch for Spicebird
[13:48] <fta2> asac, orbit is a corba client (maybe server too)
[13:48] <fta2> it's supposed to be deprecated in gnome
[13:48] <asac> fta2: yes. gconf seems to use it though :/
[13:51] <sunilmohan> Also, removing FORTIFY_SOURCE in mozilla applications not the right thing. The crashes are due to unfixed problems. I have reopened the upstream bug and submitted patches: https://bugzilla.mozilla.org/show_bug.cgi?id=412610
[13:59] <asac> sunilmohan: we dont remove FORTIFY SOURCE anymore afaik
[13:59] <asac> sunilmohan: we just use the patch that landed
[13:59] <asac> could be that we dont have that on tbird branch yet
[13:59] <asac> fta2: ^^ ?
[14:00] <sunilmohan> asac: the landed patch is not enough AFAIK, atleast for thunderbird
[14:02] <asac> sunilmohan: seems like your last patch is ready for landing
[14:02] <fta2> asac, it may still be in my tb3 branch (not sure), but it's not meant to be there anymore, i prefer the patch, but upstream is still unsure as it touches several modules
[14:02] <fta2> i'll have a look when i have time
[14:02] <asac> sunilmohan: do all r+ patches still need to be committed?
[14:03] <sunilmohan> fta2: upstream review+ed changes in other modules also (except one which is still pending)
[14:03] <sunilmohan> asac: yes! except the one that was committed originally rest need to be checked in
[14:04] <sunilmohan> asac: last three patches need sr also.
[14:04] <fta2> the patch in xul & ff has been r- and needed to be split to have separate reviews
[14:04] <fta2> some parts got a r+
[14:04] <asac> sunilmohan: who is not superreveiwer
[14:04] <asac> ?
[14:05] <asac> sunilmohan: bholley
[14:05] <asac> ?
[14:05] <asac> benjamin and roc are superreviewers
[14:05] <sunilmohan> so its ok if they don't give a sr explicitly if they are superreviews?
[14:06] <asac> i think so ... at least thats what reed tells me all the time ;)
[14:06] <asac> and there frequently land patches with just r=roc ;)
[14:06] <sunilmohan> ok :)
[15:56] <jcastro> asac: hand wavy estimate, how many patches would you say you've sent to network-manager these past 2 cycles?
[15:57] <jcastro> like, a bunch, a few, etc?
[16:11] <asac> a bunch ;)
[16:11] <asac> jcastro: why past 2 cycles?
[16:12] <jcastro> asac: I'm just trying to determine if it's enough to ask upstream to participate in a survey
[16:13] <jcastro> since we're hitting up n-m during a hug day I wanted to know how upstream feels about our patches
[16:15] <asac> jcastro: ask him about intrepid cycle
[16:15] <jcastro> ok
[16:15] <jcastro> it's primarily dan williams right?
[16:15] <asac> jcastro: you can look at the mailing list month per author
[16:15] <jcastro> nod
[16:15] <asac> i also sent a few through bugzilla
[16:15] <asac> http://mail.gnome.org/archives/networkmanager-list/2008-October/author.html
[16:16] <jcastro> ta
[16:16] <asac> http://mail.gnome.org/archives/networkmanager-list/2008-September/author.html
[16:16] <asac> and so on
[16:16] <jcastro> thank you sir
[16:16] <asac> jcastro: yes mostly Dan
[16:17] <asac> jcastro: I expect that his claims will not be really objective as he - as upstream - obviously wants more ;) ... but should hav at least improved considerably
[16:17] <jcastro> yeah they always say that.
[16:18] <jcastro> I am not really concerned about gathering that kind of statistics because we'll always not have enough
[16:18] <jcastro> mostly I am taking a measure of how patches are going back and forth amongst a group of projects to get and idea of how it's going
[16:18] <jcastro> so that when someone says "ubuntu doesn't send patches" I have hard data to say otherwise
[16:19] <asac> jcastro: i think the best way to do that is to look at the amount of patches we have in the package
[16:19] <asac> jcastro: compare 0.6 (hardy) vs. 0.7 (intrepid) package
[16:20] <jcastro> oh hey, for the nm bugs, there's not many open upstream tasks
[16:20] <asac> because when we dont have patches there, we cannot send them upstream ;)
[16:20] <jcastro> heh
[16:20] <asac> jcastro: we dont use bugzilla really
[16:20] <asac> jcastro: its a mixed thing
[16:20] <asac> jcastro: bugzilla and mailing list
[16:20] <asac> all real issues get discussed on irc and fixed on ml
[16:20] <jcastro> ok so that's why there's not many upstream linkages?
[16:21] <asac> one reason
[16:35] <asac> jcastro: i will not change my upstreaming behaviour until gnome and mozilla have the launchpad plugin so i dont need to do senseless proxying after forwarding bugs
[16:36] <asac> jcastro: current mode of operation is to spot really important issues and drive them in a way that they get fixed
[16:36] <asac> at best upstream ... if not possible downstream
[16:37] <asac> thats difficult enough. I saw a bunch of gnome bugs where they just forwarded random crash backtraces. thats one approach, but i strongly believe its not the right approach
[16:37] <asac> (not saying my approach is better - i see the deficiencies, which require resources to fix)
[16:38] <asac> so what we need to get the right way of doing things is:
[16:38] <asac> a) launchpad plugins everywhere (maintainer like me just needs to figure out whether its upstream, properly file it upstream against the right component and then monitor discussion between reporter and upstream)
[16:39] <asac> b) use upstream crash report system
[16:39] <jcastro> asac: hey, I'm just gathering info, I didn't say anything about changing the way you work!
[16:39] <asac> c) QA resources that properly triage bugs ;)
[16:40] <asac> jcastro: sure ... just wanted to make that point anyway ;)
[16:40] <jcastro> heh, I know, I get that lot. :p
[16:40] <asac> but a) would remove the urgent need for QA resources for new bugs
[16:40] <asac> i think i could cope quiet well with the inflowing ones
[16:41] <asac> once a) is there we would need a one time effort to clean all the cruft up that accumulated over time
[16:41] <asac> which is quite a lot
[16:42] <asac> jcastro: also being able to split components for big packages in launchpad would be precious ... bugt i think i already mntioned that before
[16:42] <asac> but otoh, if all goes upstream because a) exists we might not need it in LP as its properly categorized in upsream racker then
[16:42] <jcastro> yeah don't worry we'll spend alot of time talking about this in berlin, heh
[16:42] <jcastro> I just want to gather info before hand
[16:44] <asac> jcastro: sure. do you know whether gnome would be perceptive for installing the launchpad plugin? have you asked?
[16:45] <jcastro> that is a long and bitter struggle
[16:45] <jcastro> basically, they have a very customized 2.x install
[16:45] <jcastro> and moving to 3.x would be very painful
[16:45] <jcastro> they want to move, (the plugins are now in upstream bugzilla btw)
[16:45] <jcastro> but they are kind of stuck in a bad place at the moment.
[16:47] <asac> jcastro: hmm ... sme for mozilla? during UDS the bugzilla admins there seemed to be open to drive this forward
[16:47] <asac> s/sme/same/
[16:48] <jcastro> I am unsure on the status of mozilla but I know it's on the list.
[16:48] <jcastro> I believe kiko is working that himself, I will ask though
[16:51] <[reed]> I made a call
[16:51] <[reed]> I will not add the launchpad plugin to Bugzilla until launchpad is open source
[16:51] <asac> [reed]: isnt the launchpad plugin opensource?
[16:51] <[reed]> I don't think it makes sense for Mozilla to support a closed bug tracker
[16:52] <[reed]> it may be, but it still doesn't make sense to support launchpad first before supporting integration with other bug tracking systems (like other bugzilla instances, for example).
[16:52] <asac> where did you communicate that?
[16:53] <[reed]> I mentioned it in #mozwebtools a while ago... don't think I've said anything to kiko yet
[16:53] <[reed]> brb in 10 min.
[16:53] <asac> [reed]: isnt there a difference? lp plugin is ready
[16:53] <asac> bug bz vs. bz doesnt do that?
[16:53] <asac> you should communicate that
[16:53] <asac> blog about it ... if its an official decision
[16:53]  * asac off shopping
[17:15] <NCommander> Is there any reason why the version of Sunbird installed by default is debranded?
[17:22] <vadi2> Hi. My firefox decided to start crashing on gmail now, but I'm unable to find the instructions on how to provide the backtrace for it. Does anyone have them handy?
[18:01] <vadi2> Solved, I think... flash was acting up. It's happy now.
[18:13] <fta2> jcastro, did you decide which workflow you wanted to stick with for gwibber? 1 or 2 branches? deb only branch or merged branch? --export-upstream or tarball with get-orig-source? etc
[18:15] <jcastro> fta2: I have no idea. Mind if I wait 2 weeks so I can sit down with asac and have him explain to me exactly how to do this?
[18:16] <jcastro> I've only ever bumbled around in a PPA, I have no actual workflow
[18:16] <jcastro> but I am hoping to learn a way to do it smartly
[18:17] <fta2> ok, no problem, i'll follow my own idea in my ppa until you decide, without impacting the team branch
[18:20] <fta2> i also like incremental changelog, until it is really pushed to the repository.
[18:23] <fta2> jcastro, ^^
[18:24] <jcastro> what do you mean?
[18:27] <fta2> we keep the changelog open with UNRELEASED until we really push to universe or main. PPA doesn't count, so we add new entries in there, we bump the version/date/etc when needed.
[18:28] <fta2> look at our *.head branches
[18:30] <jcastro> ah I see
[18:32] <fta2> to maintain my ppa, i have one clone per arch for each branch. that's where i close the UNRELEASED, not in the main branch
[18:32] <fta2> (i use a script, it's not manual)
[18:32] <fta2> http://bazaar.launchpad.net/~fta/+junk/ppa-scripts/files
[18:35] <fta2> in a nutshell, when i want to push, lets say firefox-3.2.head to my ppa, i run sync-ppa.pl firefox-3.2, it will create/update the 3 ppa branches (ff-3.2.head.ppa.hardy/jaunty)..
[18:36] <fta2> i just have to paste the dput command that the script created
[18:36] <fta2> but well, i'm lazy, 1 or 2 commands is all i'm willing to do to update my ppa
[18:39] <fta2> ok, i have to run, beer time, cu
[20:24] <Jazzva> ubiquity.xpi has some binaries... will have to build it from source.
[21:52] <Jazzva> hmm... having libubiquity.so and ubiquity.xpt (binary files) in source package is bad, right?
[21:52] <Jazzva> since the source grabbed from hg repository contains them too...
[22:00] <asac> Jazzva: of course
[22:00] <asac> Jazzva: its not platform independent
[22:00] <asac> Jazzva: we need to build from real hg sources
[22:00] <asac> yeah
[22:01] <Jazzva> asac: but I thought I grabbed the real hg sources :)
[22:01] <Jazzva> I just followed their instructions presented at https://wiki.mozilla.org/Labs/Ubiquity/Ubiquity_0.1_Development_Tutorial#Getting_the_Source
[22:02] <Jazzva> and the source still contains those files... guess I'll see at #ubiquity channel if we can rebuild them somehow
[22:03] <asac> Jazzva: are there .so files in a hg clone?
[22:04] <Jazzva> mhm
[22:04] <Jazzva> here http://hg.toolness.com/ubiquity-firefox/file/2c70735eb550/ubiquity/platform/Linux_x86-gcc3/components
[22:04] <asac> http://hg.toolness.com/ubiquity-firefox
[22:04] <asac> i guess tahts just as a convenience there
[22:04] <asac> so users can more easily work on js
[22:04] <asac> we should santize the tarball then
[22:04] <Jazzva> there are also for Windows and Mac OS X... but we can remove those
[22:04] <asac> as long as the sources are there
[22:05] <asac> otherwise it wouldnt be free software ;)
[22:05] <Jazzva> right... I'll try to rebuild them (after dinner)
[22:05] <fta> back
[22:06] <Jazzva> asac: ah... I should read better :). print "    build-components - build C++ XPCOM components"
[22:11] <fta> asac, damn, i wanted to add something into liferea
[22:12] <asac> fta: to SRU?
[22:12] <fta> oh, it's the sru, nm
[22:15] <fta> hm, my 18M adsl is in fact ~9.2M :(
[22:25] <asac> fta: how do you measure?
[22:26] <fta> my last apt-get upgrade, with the netspeed_applet2 applet
[22:26] <fta> not rocket science
[22:27] <fta> i just upgraded my adsl service from 8M to 18M + 3G for just 2.50€ more
[22:32] <asac> i will switch provider and go from 16 (effectively 8) to 32 and will pay 17 EUR less ;)
[22:32] <fta> asac, how much?
[22:32] <asac> 22,90
[22:32] <fta> for 32M ?
[22:33] <asac> http://www.kabeldeutschland.de/highspeed-internet/pakete_tarif_uebersicht.html
[22:33] <asac> the middle thing ;)
[22:33] <asac> and 2M up ;)
[22:33] <asac> (which is what is more important for me)
[22:33] <asac> cable ;)
[22:34] <fta> my box says 11.9M / 0.9M, not sure where the truth is
[22:35] <asac> my dsl has officially 16 / 1
[22:35] <asac> but its really more like 8 / .500
[22:35] <fta> i could take the fiber but i don't really need that
[22:35] <asac> if its top-performing
[22:35] <asac> sometimes more like .700 / .020 ;)
[22:35] <fta> lol
[22:35] <asac> i couldnt take that ... but i cant stand instability anymore ... and suddenly there is this great offer ;) (which wasnt available before in my house)
[22:36] <asac> fiber isnt anywhere here ... cable is probably the best that exists
[22:36] <fta> i have the choice between *dsl, cable and ftth
[22:37] <asac> my mother has some kind of cable thing, but its fiber right from the street afaik
[22:37] <asac> not sure if thats normal ;)
[22:38] <asac> i actually dont want to care. i only go crazy when i have disconnects or lame uploads - especially to debian.
[22:49]  * asac doing reconnect stuff ... probably off for a while
[22:58] <Lns> Ok, a free pizza to anyone who can fix this longstanding bug =) https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/19033
[22:59] <Lns> asac: fta: The issue we were working on before regarding entropy in FF3 has been fixed with the PPA pkg - thank you!!!
[23:00] <fta> :)
[23:18] <fta> Lns, what do you get as home page when you start ff?
[23:23] <Lns> fta: my normal homepage that i set as a normal user
[23:23] <Lns> and the default start.ubuntu.com if its a new prof
[23:27] <fta> Lns, you have ubufox installed, right?
[23:36] <Lns> fta: yes, i believe so
[23:36] <Lns> fta: yes
[23:36] <fta> it overwrites the homepage
[23:36] <fta> unless the user changed it
[23:37] <fta> so it looks like your bug
[23:37] <Lns> are you kidding??
[23:38] <Lns> hold on, im on the phone but i'll test in a min
[23:45] <fta> http://bazaar.launchpad.net/~ubuntu-core-dev/ubufox/ubuntu/annotate/head%3A/content/startpage.html
[23:50] <Lns> fta: disabling ubufox and using: lockPref("browser.startup.homepage", "www.google.com"); in /etc/firefox/pref/firefox.js doesn't work :(
[23:51] <fta> which ff ?
[23:51] <fta> Lns, ^^
[23:53] <Lns> fta: 3.0.5+nobinonly-0ubuntu0.8.04.1
[23:53] <fta> so it's /etc/firefox-3.0/pref/firefox.js
[23:54] <Lns> right