=== asac_ is now known as asac [09:59] * asac reboots to new kernel [10:20] that didnt work out :/ === asac_ is now known as asac [11:39] fta2: ok so test_handlerService.js seems to fail if gconf is not available ... so screen/chroot etc. [11:39] hmm [11:40] so the gconfd needs to be started most likely [12:23] asac, you are referring to -testsuite, right? [12:26] fta2: to make check in general [12:26] for me the OS handler stuff fails when running that in a screen [12:27] file a bug and fix it :) [12:28] not really fixable i think [12:28] unless i know how to start gconf in screen [12:29] ask seb, he should have plenty of packages doing just that at build time [12:29] gconf testing? [12:46] http://alioth.debian.org/docman/view.php/30046/2/menu-one-file.html#s3.7 [13:21] js> Components.classes["@mozilla.org/browser/shell-service;1"].getService(Components.interfaces.nsIShellService).desktopBackgroundColor = 0xFFEEAA; [13:21] 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] so seems its orbit [13:37] what the hell is orbit? there is no server? i dont see a binary [13:40] welcome sunilmohan ;) [13:41] asac: hi :) [13:42] I am helping wikz with Spicebird packaging [13:42] I saw a patch with unix/packages-static file [13:42] yeah ... now that i read your name careful i figure that [13:43] sunilmohan: that patch isnt wanted upstream afaik. fta2 did it for tbird (if you refer to tbird patch) [13:43] actually I was also worried about it. [13:44] windows/packages-static and installer/Makefile.in (list of files to exclude) are pain to maintain [13:45] many times we forgot something or the other in these two files and removed-files and had major problems [13:45] unix/packages-static looks like another problem if we have to maintain it [13:46] I think some who reusing the exclusion list from installer/Makefile is a better idea. [13:47] so for now asking wikz not to prepare a similar patch for Spicebird [13:48] asac, orbit is a corba client (maybe server too) [13:48] it's supposed to be deprecated in gnome [13:48] fta2: yes. gconf seems to use it though :/ [13:51] 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:51] Mozilla bug 412610 in Startup and Profile System "MAXPATHLEN too small for glibc's realpath()" [Normal,Reopened] [13:59] sunilmohan: we dont remove FORTIFY SOURCE anymore afaik [13:59] sunilmohan: we just use the patch that landed [13:59] could be that we dont have that on tbird branch yet [13:59] fta2: ^^ ? [14:00] asac: the landed patch is not enough AFAIK, atleast for thunderbird [14:02] sunilmohan: seems like your last patch is ready for landing [14:02] 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] i'll have a look when i have time [14:02] sunilmohan: do all r+ patches still need to be committed? [14:03] fta2: upstream review+ed changes in other modules also (except one which is still pending) [14:03] asac: yes! except the one that was committed originally rest need to be checked in [14:04] asac: last three patches need sr also. [14:04] the patch in xul & ff has been r- and needed to be split to have separate reviews [14:04] some parts got a r+ [14:04] sunilmohan: who is not superreveiwer [14:04] ? [14:05] sunilmohan: bholley [14:05] ? [14:05] benjamin and roc are superreviewers [14:05] so its ok if they don't give a sr explicitly if they are superreviews? [14:06] i think so ... at least thats what reed tells me all the time ;) [14:06] and there frequently land patches with just r=roc ;) [14:06] ok :) [15:56] asac: hand wavy estimate, how many patches would you say you've sent to network-manager these past 2 cycles? [15:57] like, a bunch, a few, etc? [16:11] a bunch ;) [16:11] jcastro: why past 2 cycles? [16:12] asac: I'm just trying to determine if it's enough to ask upstream to participate in a survey [16:13] since we're hitting up n-m during a hug day I wanted to know how upstream feels about our patches [16:15] jcastro: ask him about intrepid cycle [16:15] ok [16:15] it's primarily dan williams right? [16:15] jcastro: you can look at the mailing list month per author [16:15] nod [16:15] i also sent a few through bugzilla [16:15] http://mail.gnome.org/archives/networkmanager-list/2008-October/author.html [16:16] ta [16:16] http://mail.gnome.org/archives/networkmanager-list/2008-September/author.html [16:16] and so on [16:16] thank you sir [16:16] jcastro: yes mostly Dan [16:17] 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] yeah they always say that. [16:18] I am not really concerned about gathering that kind of statistics because we'll always not have enough [16:18] 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] so that when someone says "ubuntu doesn't send patches" I have hard data to say otherwise [16:19] jcastro: i think the best way to do that is to look at the amount of patches we have in the package [16:19] jcastro: compare 0.6 (hardy) vs. 0.7 (intrepid) package [16:20] oh hey, for the nm bugs, there's not many open upstream tasks [16:20] because when we dont have patches there, we cannot send them upstream ;) [16:20] heh [16:20] jcastro: we dont use bugzilla really [16:20] jcastro: its a mixed thing [16:20] jcastro: bugzilla and mailing list [16:20] all real issues get discussed on irc and fixed on ml [16:20] ok so that's why there's not many upstream linkages? [16:21] one reason [16:35] 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] jcastro: current mode of operation is to spot really important issues and drive them in a way that they get fixed [16:36] at best upstream ... if not possible downstream [16:37] 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] (not saying my approach is better - i see the deficiencies, which require resources to fix) [16:38] so what we need to get the right way of doing things is: [16:38] 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] b) use upstream crash report system [16:39] asac: hey, I'm just gathering info, I didn't say anything about changing the way you work! [16:39] c) QA resources that properly triage bugs ;) [16:40] jcastro: sure ... just wanted to make that point anyway ;) [16:40] heh, I know, I get that lot. :p [16:40] but a) would remove the urgent need for QA resources for new bugs [16:40] i think i could cope quiet well with the inflowing ones [16:41] once a) is there we would need a one time effort to clean all the cruft up that accumulated over time [16:41] which is quite a lot [16:42] 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] 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] yeah don't worry we'll spend alot of time talking about this in berlin, heh [16:42] I just want to gather info before hand [16:44] jcastro: sure. do you know whether gnome would be perceptive for installing the launchpad plugin? have you asked? [16:45] that is a long and bitter struggle [16:45] basically, they have a very customized 2.x install [16:45] and moving to 3.x would be very painful [16:45] they want to move, (the plugins are now in upstream bugzilla btw) [16:45] but they are kind of stuck in a bad place at the moment. [16:47] jcastro: hmm ... sme for mozilla? during UDS the bugzilla admins there seemed to be open to drive this forward [16:47] s/sme/same/ [16:48] I am unsure on the status of mozilla but I know it's on the list. [16:48] 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] [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] 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] [reed]: isnt there a difference? lp plugin is ready [16:53] bug bz vs. bz doesnt do that? [16:53] you should communicate that [16:53] blog about it ... if its an official decision [16:53] * asac off shopping [17:15] Is there any reason why the version of Sunbird installed by default is debranded? [17:22] 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] Solved, I think... flash was acting up. It's happy now. [18:13] 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] 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] I've only ever bumbled around in a PPA, I have no actual workflow [18:16] but I am hoping to learn a way to do it smartly [18:17] ok, no problem, i'll follow my own idea in my ppa until you decide, without impacting the team branch [18:20] i also like incremental changelog, until it is really pushed to the repository. [18:23] jcastro, ^^ [18:24] what do you mean? [18:27] 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] look at our *.head branches [18:30] ah I see [18:32] 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] (i use a script, it's not manual) [18:32] http://bazaar.launchpad.net/~fta/+junk/ppa-scripts/files [18:35] 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] i just have to paste the dput command that the script created [18:36] but well, i'm lazy, 1 or 2 commands is all i'm willing to do to update my ppa [18:39] ok, i have to run, beer time, cu === rzr is now known as rZr [20:24] ubiquity.xpi has some binaries... will have to build it from source. [21:52] hmm... having libubiquity.so and ubiquity.xpt (binary files) in source package is bad, right? [21:52] since the source grabbed from hg repository contains them too... [22:00] Jazzva: of course [22:00] Jazzva: its not platform independent [22:00] Jazzva: we need to build from real hg sources [22:00] yeah [22:01] asac: but I thought I grabbed the real hg sources :) [22:01] I just followed their instructions presented at https://wiki.mozilla.org/Labs/Ubiquity/Ubiquity_0.1_Development_Tutorial#Getting_the_Source [22:02] and the source still contains those files... guess I'll see at #ubiquity channel if we can rebuild them somehow [22:03] Jazzva: are there .so files in a hg clone? [22:04] mhm [22:04] here http://hg.toolness.com/ubiquity-firefox/file/2c70735eb550/ubiquity/platform/Linux_x86-gcc3/components [22:04] http://hg.toolness.com/ubiquity-firefox [22:04] i guess tahts just as a convenience there [22:04] so users can more easily work on js [22:04] we should santize the tarball then [22:04] there are also for Windows and Mac OS X... but we can remove those [22:04] as long as the sources are there [22:05] otherwise it wouldnt be free software ;) [22:05] right... I'll try to rebuild them (after dinner) [22:05] back [22:06] asac: ah... I should read better :). print " build-components - build C++ XPCOM components" [22:11] asac, damn, i wanted to add something into liferea [22:12] fta: to SRU? [22:12] oh, it's the sru, nm [22:15] hm, my 18M adsl is in fact ~9.2M :( [22:25] fta: how do you measure? [22:26] my last apt-get upgrade, with the netspeed_applet2 applet [22:26] not rocket science [22:27] i just upgraded my adsl service from 8M to 18M + 3G for just 2.50€ more [22:32] i will switch provider and go from 16 (effectively 8) to 32 and will pay 17 EUR less ;) [22:32] asac, how much? [22:32] 22,90 [22:32] for 32M ? [22:33] http://www.kabeldeutschland.de/highspeed-internet/pakete_tarif_uebersicht.html [22:33] the middle thing ;) [22:33] and 2M up ;) [22:33] (which is what is more important for me) [22:33] cable ;) [22:34] my box says 11.9M / 0.9M, not sure where the truth is [22:35] my dsl has officially 16 / 1 [22:35] but its really more like 8 / .500 [22:35] i could take the fiber but i don't really need that [22:35] if its top-performing [22:35] sometimes more like .700 / .020 ;) [22:35] lol [22:35] 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] fiber isnt anywhere here ... cable is probably the best that exists [22:36] i have the choice between *dsl, cable and ftth [22:37] my mother has some kind of cable thing, but its fiber right from the street afaik [22:37] not sure if thats normal ;) [22:38] 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] Ok, a free pizza to anyone who can fix this longstanding bug =) https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/19033 [22:58] Launchpad bug 19033 in firefox "systemwide default startup homepage ignored" [Medium,Confirmed] [22:59] asac: fta: The issue we were working on before regarding entropy in FF3 has been fixed with the PPA pkg - thank you!!! [23:00] :) [23:18] Lns, what do you get as home page when you start ff? [23:23] fta: my normal homepage that i set as a normal user [23:23] and the default start.ubuntu.com if its a new prof [23:27] Lns, you have ubufox installed, right? [23:36] fta: yes, i believe so [23:36] fta: yes [23:36] it overwrites the homepage [23:36] unless the user changed it [23:37] so it looks like your bug [23:37] are you kidding?? [23:38] hold on, im on the phone but i'll test in a min [23:45] http://bazaar.launchpad.net/~ubuntu-core-dev/ubufox/ubuntu/annotate/head%3A/content/startpage.html [23:50] fta: disabling ubufox and using: lockPref("browser.startup.homepage", "www.google.com"); in /etc/firefox/pref/firefox.js doesn't work :( [23:51] which ff ? [23:51] Lns, ^^ [23:53] fta: 3.0.5+nobinonly-0ubuntu0.8.04.1 [23:53] so it's /etc/firefox-3.0/pref/firefox.js [23:54] right