[00:04] mconnor: ok managed to test the patch and attached to bug [00:04] https://bugzilla.mozilla.org/show_bug.cgi?id=515232 [00:04] Mozilla bug 515232 in Search ""distribution" searchplugins dont work for complex general.useragent.locale" [Normal,Assigned] [00:05] hmm. guess the autostring should be moved directly above where its used for first time ;) [00:09] asac, if tomorrow gnomefreak will ask about ubuntu-it-menu tell him I gonna do it tomorrow afternoon / evening [00:10] andv: you think he will jump on it? [00:10] asac, lol [00:10] asac, maybe he asks you to sponsor it [00:10] k [00:10] I first need to fix the extra license file [00:10] then it's ready [00:11] but now I'm a bit tired, so commenting two more bugs than I'm off [00:11] thx [00:11] sleep well [00:11] ty :) [00:23] asac, ok, done, I'm off for night [00:24] asac, see ya tomorrow, good night [01:26] micahg: quick question before i leave. did things go well with the patch merging? ;) [01:26] micahg: also not happy i couldnt follow here - was kind of dragged through something ;) [01:28] asac, i thought you did a session about that during the summer.. [01:28] that session was kind of half awake ;) [01:28] i cant remember it anymore [01:28] was like 0400 UTC ;) [01:29] i think i actually explained the way we do things [01:29] wow [01:29] yes [01:29] thats what i am thinking now [01:29] i was like 2 minutes awake when the session started ;) [02:16] just tested peacekeeper, ff trunk scored 1340, chromium 2086 [02:18] fta: does chromium work on arm? [02:19] not sure it's ready, i saw some patches recently [02:19] ok [02:24] http://www.sofaraway.org/ubuntu/tmp/peacekeeper-090709.png [02:29] asac, well, no, it will sure fail for sure on the other arches, that's why i kept it like that [02:29] -sure [02:31] fta: yes. [02:31] but its wrong ;) [02:31] you dont put specific archs in it unless the app is inheritently arch-specific [02:34] the idea is: you upload, build fails. porters start working on it ;) [02:34] in debian its only an important bug and nor a RC bug if a package fails to build somewhere where it never built before [02:34] so a bit the "always try ... maybe it starts to work" approach ;) [02:34] ok off [02:35] ttyt === jtv1 is now known as jtv === jtv is now known as jtv-eat [08:53] mornign guys [08:53] andv: got your response on the bug of ubuntu-it-menu and its not a problem at all [11:11] jdstrand: so is going to be today ;) ... let me know when awake [11:11] so, release is going ... [11:11] ;) [11:43] is there a sound channel? [11:57] gnomefreak: ubuntu-sound ;) [11:57] no clue [12:01] asac, the chromium really wants us to stick with in-source sqlite [12:01] the preload patch is a perf killer [12:01] yes [12:02] but upstream seems to have rejected the patch [12:04] asac: no i tried that. im think #ubuntu-pulseaudio but not sure. i will check in a few minutes [12:07] asac, as expected, ff3.7 refuses to start once again [12:08] asac, any idea where i can set a breakpoint? [12:10] well. if it exists cleanly, so it seems it thinks all is fine ;) [12:11] hard to tell where in the startup sequence it goes crazy [12:17] needs lots of debug prints i would think [12:17] gasp [12:17] fta2: what firefox does is: it queries the X tree to find firefox windows [12:17] then selects the one with the right version+profile [12:17] and sends a command [12:18] no ff at all [12:18] yes. but thats what it does [12:18] now you get all those bandaid errors [12:18] which on its own is a bad thing, because that means that the query of x tree failed [12:19] but the code is supposed to assume that no window is running if thats the case [12:19] might be a bug in that [12:19] but doesnt explain why it works once [12:19] fta2: have you tried to remove plugins etc.? [12:19] there were issues with flash at some point that caused similar issues [12:20] with NSPR_LOG_MODULES all:5 http://paste.ubuntu.com/267869/ [12:20] new kernel doesnt promt for restart. is this grub or something else im missing? [12:22] 207996688[7f670b362150]: nsNativeModuleLoader::Init() [12:22] i assume thats in the forked process? [12:23] 207996688[7f670b362150]: DOCSHELL 7f670b2bc000 created [12:23] 207996688[7f670b362150]: nsWindow::Destroy [7f670b3df8f0] [12:23] no clue why something like that would happen [12:23] fta2: what was the strace -f -eopen firefox again? [12:26] asac, http://paste.ubuntu.com/267871/ [12:30] fta2: nightly.xpt? [12:30] nightly tester tools? [12:30] yes [12:30] -safe-mode? [12:31] and/or fresh profile? [12:31] both are ok [12:32] hm, and now it starts [12:32] like with a --reinstall [12:44] i erally wish mozilla would have kept the release schedule icals [12:44] really* [12:44] * gnomefreak reboots [13:07] fta2: yeah. track down the extension causing this. maybe refractor? [13:07] fta2: does fresh profile start two times in a row? [13:34] asac: are we removing ${misc:Depends} from control [13:34] from non-transitional entry [13:38] no. thats ok to have [13:39] asac: hi, I'm here. firefox testing today? [13:42] jdstrand: yep ;) [13:43] asac: ok cool [13:43] asac: I'm on it. can you ping me when you are satisfied with your testing and it's ok for me to publish? [13:44] yesa [13:44] jdstrand: release is as usually late though [13:45] asac: btw, that is ff3 3.0.14 and xl19 1.9.0.14 (hardy-karmic), ff35 3.5.3 and xl191 1.9.1.3 (karmic only)? [13:52] fta2: is chromium using GL as skia backend? [13:55] asac, http://code.google.com/p/chromium/wiki/LinuxGraphicsPipeline [13:58] bug 425715 [13:58] Launchpad bug 425715 in mozgest "mozgest using an older version of mozilla-devscripts" [Undecided,New] https://launchpad.net/bugs/425715 [14:06] andv: are you around yet. just finished with mozgest debdiff is on bug above and no lintian warnings/errors [14:08] ok branch is pushed as well [14:13] gnomefreak: he said to tell you that he will do mozgest today [14:13] asac: already done :( [14:31] hey guys [14:32] hi eagles0513875 [14:33] if i can help out wiht packaging ill help you guys out [14:33] put my quad to good use lol [14:34] and bug 425695 is done and branch pushed to extension team [14:34] Launchpad bug 425695 in adblock-plus "adblock-plus needs xpi:depends changed to recommends" [Undecided,New] https://launchpad.net/bugs/425695 [14:34] my quota is met for the day now email before it gets too late in morning [14:40] Subject: You can say ?good-bye? to your old ugly watch. << my damn watches are fine [14:56] ahhah viva la sapm [14:56] :spam [14:56] :) i got news for u guys :) [14:56] gnomefreak: lp: #... is missing in http://bazaar.launchpad.net/~mozilla-extensions-dev/firefox-extensions/adblock-plus.ubuntu/revision/49 [14:57] bdrung_: yeah i keep forgetting to add that in there. on all extensions so far. i will fix it mostlikely tomorrow or if i have time after email ill do it real fast [14:58] asac: ok bug 107247 since all gecko browsers see it wouldnt it be against xulrunner instead of firefox? [14:58] Launchpad bug 107247 in malone "Launchpad bug pages trigger caret browsing in Firefox and other Gecko browsers" [High,Fix committed] https://launchpad.net/bugs/107247 [15:09] gnomefreak: is sunbird 0.9 ready? [15:09] i think i failed completely on that? [15:11] asac: any reason why the nm-applet does not animate for wired connections? it constantly uses only the network-idle icon , while the netwrk-send, *-transmit , *-send-receive are not used? [15:12] mac_v: not sure what you mean [15:12] you want traffic indication in the applet? [15:14] yeah [15:16] that does not work for any type of connection [15:16] also blinking in the tray is not what we will do [15:16] a statistic info somewhere we are planning [15:16] especially for 3g etc. so users can see the costs [15:17] asac: /status/24/network-idle.svg /status/24/network-receive.svg /status/24/network-transmit.svg /status/24/network-transmit-receive.svg [15:17] these icons exist , ^ [15:17] which is the icon that is going to be used? [15:22] mac_v: no icons [15:22] asac: they are in the /usr/share/icons/THEMENAME [15:22] the tray will not be animated [15:22] thats not a problem [15:23] thats why we dont need new icons ;) [15:23] asac: i wanted to know which icon will be used :) [15:23] not sure i understand the question [15:23] fo what? [15:23] for the notification area [15:23] as i said: "the tray will not be animated". so none of those [15:23] yes. not sure how to answer that different from what i said [15:24] asac: hehe , ok , so which icon is going to be assigned , could you pls have a look :) we are making icons for humanity [15:25] can you please read what i wrote [15:25] the (icon in the) tray will not be animated == will not show activity indication [15:26] asac: thats fine , but it will use an icon , right? a non animated one? [15:26] network manager already uses an icon [15:27] http://paste.ubuntu.com/267971/ [15:27] it uses the one of the devbice type of the primary route [15:28] asac: ah those , ,thanks :) [15:28] we were confused over the icons [15:30] asac: because the icons we had assigned were those listed above , the status icons and nm was using only the idle one , so testers reported it :) , just wanted to know which icon to assign... thanks for clearing that up :) [15:31] it might feel like its the old idle icon [15:32] but NM uses complete different set [15:32] than the old network indicator [15:32] oh... ok [15:39] asac: yes sunbird .9 is ready its version ubuntu3 as i recall [15:49] bdrung_: fixed the changelog in adblock-plus and mozgest. [15:49] good [15:50] i forgot those are not being pushed to Debian (or at least doesnt have to be) might be a good idea unless they already have them [15:51] asac: seamonkey 1.1.18 is going to have to wait until after honeymoon ( 1 week to 2 weeks) not sure how much longer than a week we are staying [15:52] unless someone gets energetic and wants to go for it ( im thinking a bit hard for eagles0513875) but since mike pushed 1.1.18 we should beable to take patches/fixes from there and add it to ours and build [15:53] updates -> meetings -> bed -> start next day [16:18] ok i will try to be here tomorrow for a little bit, i have to pack rest of stuff tomorrow and hit airport Friday morning. [16:26] asac, d'oh! chromium-browser (4.0.207.0~svn20090908r25615 -> 4.0.208.0~svn20090909r25716) [88.76MB (+18850kB, +21.23%)] [16:27] sigh [16:27] icu42 [16:27] maybe we should prepare the first upload based on yesterdays package [16:27] there are 2 icu now [16:36] transition [16:37] fta@cube:/data/bot/upstream/chromium-browser.svn/src/third_party $ du -sm icu* [16:37] 298 icu [16:37] 268 icu38 [16:48] fta2: is that a transitional situation? [16:48] yes [16:49] any known timeline? [17:04] i will ask [17:16] asac: ff3.5 is the hugday target... [17:16] today? [17:16] tomorrow [17:16] ah ... yeah. pedro mentioned it ;) [17:18] well, I'm subscribed to the package, so I'll try to keep an eye on it [17:18] ttyl === dpm is now known as dpm-afk [17:34] thx [17:44] asac: " wpa_supplicant[3125]: CTRL-EVENT-SCAN-RESULTS " was this what you were talking about the other day? to reduce the auto-refresh of the nm-applet? [17:44] you mean background scanning? [17:44] yup [17:44] you see that because of background scanning ... yes. [17:45] that is occurring every 2 mins! seems an over kill :/ [17:45] no [17:45] ;) [17:45] for the sake of connectivity yes. [17:45] but for the sake of other things ... no. [17:45] ;p , well it floods the log ;) [17:47] does it have to log *every* scan? wouldnt it be better when a scan has an error :) [17:48] the log can be improved. at least there should be timestamps... feel free to submit it ;) [17:49] personally i dont have many problems with that log [17:49] but if folks dont like it we can address is on contribution base [17:49] asac, hello alex [17:49] asac, what happened to the extension wiki page? It lists just few of them now [17:49] asac: well i have other errors , hence this seems to add to the haystack :( [17:55] andv: look at the changes log [17:56] https://wiki.ubuntu.com/MozillaTeam/Karmic/ExtensionReview [17:56] andv: ^^ please figure what gnomefreak did ;) [17:56] i am out for dinner now for 1-2h [17:56] revision 11 looks ok [17:56] most likely some mess happened then ;) [17:57] https://wiki.ubuntu.com/MozillaTeam/Karmic/ExtensionReview?action=info [17:57] ok out [17:57] thats what imeant [17:57] oki [18:54] asac: can the fix for bug 404827 make it into xul1.9.1.3 on jaunty? [18:54] Launchpad bug 404827 in xulrunner-1.9.1 "Firefox doesn't warn about Attack Sites!?" [Critical,Fix released] https://launchpad.net/bugs/404827 [18:56] asac, I've cleaned the page a bit, fixed links et all [18:56] asac, let me know if it's fine now [19:16] micahg: todays security update is supposed to fix that. please verify in -security ppa [19:18] hmm [19:18] seems was forgotten [19:18] too bad [19:18] yeah, I checked the security ppa first :) [19:19] it's not worth another rebuild? [19:20] asac, are the FAILED emails clear enough (see o3d today) [19:20] * asac checks [19:21] asac, wiki page updated, let me know when checked [19:21] jdstrand: can you check the xul 1.9.1 for jaunty in security ppa and tell me if that is actually ok with you? [19:22] http://launchpadlibrarian.net/31543792/buildlog_ubuntu-karmic-i386.xulrunner-1.9.2_1.9.2~a2~hg20090909r31589%2Bnobinonly-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz [19:22] jdstrand: and if that is ok, also tell me if its ok to add --enable-safe-browsing for this update still (bug 404827) [19:22] Launchpad bug 404827 in xulrunner-1.9.1 "Firefox doesn't warn about Attack Sites!?" [Critical,Fix released] https://launchpad.net/bugs/404827 [19:22] http://launchpadlibrarian.net/31546555/buildlog_ubuntu-karmic-i386.firefox-3.7_3.7~a1~hg20090909r32341%2Bnobinonly-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz [19:22] we have that in karmic now for a while and should be safe [19:22] its universe [19:22] but its clearly not directly related to this security update [19:22] (mor so for the geolocation thing thats in the current ppa version) [19:23] fta: maybe thats alrewady fixed upstream? [19:23] looks like they should get a red on tinderbox for that ;) [19:24] i mean the test failure [19:24] sigh ... gnomeshell .. sigh [19:24] need to get upstreamred [19:24] somehow :( [19:24] micahg: ^^ [19:24] ;) [19:24] you wanted to work on that, right ;)? [19:24] patching file browser/components/shell/src/nsGNOMEShellService.h [19:24] Patch lp185622_system_path_default_browser.patch does not apply (enforce with -f) [19:26] I was [19:26] I can try again tonight [19:26] micahg: did you end up in problems yesterday while trying to adjust that patch? [19:26] or is this a new build failure? [19:27] I couldn't get quilt to give me a .rej file [19:27] hmm [19:27] ok [19:27] cd build-tree/mozilla ... ln -s ../../debian/patches; quilt push -a [19:27] quilt push -f [19:27] remove your quiltrc ;) === micahg1 is now known as micahg [19:28] mayeb that was it [19:28] I'll try again tonight unless you are going to take care of it now [19:28] just tell me when you dont get it done ;) [19:29] ok [19:29] so we have it fixed tomorrow at least .... otherwise fta will harangue us about his build-failed ratio ;) [19:29] yeah! [19:30] Total builds: 11676 [19:30] Failed 1538 [19:30] Pending 8 [19:30] Superseded 484 [19:30] Succeeded 9646 [19:30] andv: i think it looks good now. thx [19:30] ah [19:30] now continue with all the other extensions ;) [19:30] now I get the rejects :0 [19:30] :) [19:30] asac, np, everything was messed up [19:30] asac, like links done with bug ID set as xxxxx [19:30] yeah. but at least the general content was ok [19:30] i am not botherred about the right links. having them right is of course nice ;) [19:31] asac, yeah, finishing the check on ubuntu-it-menu [19:31] asac, do you know if gnomefreak finished working on any other extension? [19:31] today? [19:31] asac: I don't get the reject files though [19:32] micahg: does it complain? [19:32] i think you had something about "unified reject" in your quiltrc. not sure what that means in practice as i dont have any quiltrc ;) [19:33] micahg: maybe your reject is just inside those files? [19:33] like conflict markers inside? [19:33] asac, i didn't change the way tests are done in xul*, they should not be fatal [19:33] or there was not a problem ;) [19:33] fta: well. the test build failure is an upstream build failure [19:33] make does not find the target [19:34] thats why i think its either already fixed or they have red flag atm ;) [19:34] asac: http://pastebin.com/f5c0157ac [19:35] micahg: thats quilt push, right?= [19:35] push -f [19:35] reed is never here when we need him :P [19:35] so first: can be reverse-applied means that either exactly that patch landed upstream [19:35] or you have a busted build tree [19:35] where you alreawdy have that patch applied [19:35] i would think the latter as the firefox-profilename patch is unlikely to ever get upstreamed [19:35] micahg: start from a clean tree again [19:35] then use the link for patches [19:35] and do what you tried to do [19:35] i am sure all will be good [19:36] how do I start from a clean tree again? ./debian/rules patch? [19:37] micahg: if you dont want to start with bzr bd --merge -e you can first clean it completely: [19:37] fakeroot ./debian/rules clean [19:37] then do what you said [19:40] asac, it won't advise to call patch, clean or even pre-build (like in my dpatch script), it's easy to start the build (dpkg-buildpackage, or debuild), and fix from there [19:42] fta: patch works well nowadays. whats the problem with that? [19:43] embedded tarballs, or tweaked build dirs [19:43] or custom unpack rules [19:43] a real build would always work [19:44] er, well, fail ;) [19:48] fta: it works for embedded tarballs ... at least fo rus [19:49] for us [19:49] i hope we dont use custom unpack rules taht dont properly hook into the appropriate cdbs rules in moz and chrome etc. rules ;) [19:49] if others do that, so be it :) ... but for those you cannot even say that you can properly work on packages ;) [19:49] some are so busted that you have to trash the build tree and start from .dsc on every modification [19:50] some even make the build tree dirty during clean:: [20:09] asac, remember my dquilt? http://paste.ubuntu.com/268145/ [20:11] yes [20:15] several times, it caused me pain, creating the patches/ dir in the current dir instead of using the one in DEBIAN_PATCHES [20:15] i'm no longer using it, i build and make the symlink [20:16] asac: can do it here [20:16] hi [20:16] Pavlov: so to tell you what to do at best i have to know some things: [20:16] ok [20:16] 1. are you aiming to distribute a one package per language? [20:17] also are you shipping xulrunner separated? [20:17] we're aiming to make the installation process simple for end users, and would like to avoid having to have seperate repos per language [20:17] so yeah, we have a fennec debian package and a xulrunner ones [20:18] you want to provide "upstream" debian packages? or in some distro? [20:19] probably both. we've been working with the maemo community to push our packages to their "maemo-extras" repository [20:19] it would be great to eventually get source package files so we could more easily spin builds in distros [20:19] but right now, we're ok doing the builds. we've got things to the point where we can do repacks similar to how we do on the desktop, but we end up with a ton of seperate packages [20:20] which is ok, except we don't want to present the user with 50 fennecs to choose from [20:20] sure. [20:21] so the general approach that we use is that we ship the .xpi's in the unified language package we have in the distro [20:21] so basically ubuntu has language-pack-de ... with all the translations for software in main [20:21] when user switches language in our language selector, we install the appropriate language-pack if its not installed yet and switch the system locale [20:22] ah, so most of that work is done by the locale switcher? [20:22] not sure if maemo has a similar unified language pack ... if it does, it would make sense to have that in there [20:22] Pavlov: yes. but we try to not ship per-language-per-application packages. just one big package for "german" where all the translations are in ... [20:22] right [20:23] Pavlov: so its different way you would ship in maemo (distro) or as upstream .debs [20:23] right [20:23] for upstream you could ship one package for each locale and ask the user to install it [20:23] that package would basically just have the .xpi [20:23] right [20:23] hmm [20:23] or - if the amount of languages is small - you could make one big package [20:23] with all the .xpis [20:23] right [20:23] i wouldnt do that if its more than 8 languages [20:24] startup time ... and addons manager bustage come to my mind [20:24] yeah, it almost certainly will be [20:24] maybe not 75 or whatever firefox is up to yet [20:24] so ... technically using this approach requires you to use "matchOS" [20:24] which is something we just discussed yesterday here ;) [20:25] matchOS=true works pretty good ... except that it has a few bugs because its not the default way firefox builds are translated [20:25] it think almost all distros use that (if not all) [20:25] matchOS selects the chrome locale by the system LANG environment [20:25] like when you run locale [20:26] asac: maybe that's why I had trouble with the alpha 5 CD dictionary? [20:26] micahg: i am not sure why you had that problem ... did anyone report a dupe yet? [20:26] nope [20:26] micahg: maybe we can ask someone during tomorrows hug day to test and confirm that? [20:26] ok [20:27] asac: i see [20:27] so witch matchOS set, and the right xpi installed, things just work? [20:28] Pavlov: there are a few tiny details. [20:28] Pavlov: 1. if you have a xulrunner split you can either just ship full fennec langpacks or the partial ones next to general xulrunner ones [20:28] that comes handy if you want to use translated xulrunner somewhere else [20:28] the trick is to use toolkit@mozilla.org as the target application and split the xpi [20:28] thats what we do in ubuntu [20:29] 2. there are a few bugs sourrounding matchOS ... and its ways to mitigate those [20:29] the most important one is: useragent will not be right if you switch locale [20:29] to workaround you need to make a localized pref out of general.useragent.locale [20:29] but that triggers a few bugs in xulrunner/firefox code base [20:30] and can cause extensions that rely on general.useragent.locale being a char pref [20:30] to fail [20:30] we ship it with that localized prefs and i think the proper useragent locale is more important than the regressions that exists [20:30] due to that [20:31] if you have questions while doing this, we are here ;) [20:31] just shoot and i will reply when i see it :) [20:31] Pavlov: ^^ [20:33] ok [20:33] im going to see what we can do [20:33] thanks for your help! [20:33] welcome [20:38] asac, ubuntu-it-menu pushed [20:39] asac, the new icu: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/README.google [20:39] asac, we should add as 'checklist' to remove all extra license files with the MOZ_XPI_DOCUMENTED_LICENSE_FILES feature [20:40] asac, together with the other changes [20:42] asac, do you know if gnomefreak worked on any other package today I should look at? === dpm-afk is now known as dpm [20:49]