[00:25] something not negative if possible :P [00:26] or a nickname without bot in it but suiting the avatar [00:27] no rush, i won't do it tonight === asac_ is now known as asac [02:59] fta: ppacron? [02:59] debcron-bot? === micahg1 is now known as micahg === micahg1 is now known as micahg [05:54] [reed]: what do I do if I have a stacktrace for TB2 that matches one for FF2 that was resolved WFM [06:01] <[reed]> what is it? and what bug? [06:02] <[reed]> do you have STR? [06:08] STR? [06:08] [reed]: ? [06:09] [reed]: ? [06:09] bug 488640 and mozilla 361835 [06:09] Bug 488640 on http://launchpad.net/bugs/488640 is private [06:09] Mozilla bug 361835 in General "crash SEGV [@ nsCxPusher::Pop() ] during startup" [Critical,Resolved: worksforme] http://bugzilla.mozilla.org/show_bug.cgi?id=361835 [06:09] ugh, let me make that TB bug public [06:11] ok, it's public now [06:12] gavin: here's the Q I asked [reed]: what do I do if I have a stacktrace for TB2 that matches one for FF2 that was resolved WFM [06:13] assume it was fixed? :) [06:13] upgrade to tb3? [06:13] * gavin is kidding [06:13] not sure what context you're asking in [06:14] well, can I move to TB and reopen? [06:14] or should I file another bug in TB? [06:14] I started searching crash-stats.mozilla.com for crash reports [06:14] that's how I found it [06:15] well, it's unlikely that the problem would be fixed in tb2 unless it's very serious [06:15] given that 1.8 has been almost entirely abandoned [06:15] (especially now that tb3 is out) [06:15] gavin: ok, I'll ask the user if it's persistent or a one time thing [06:16] you 'd probably want to file a new TB bug, mark it 1.8 only, and reference 361835 [06:16] but like I said, odds of it being fixed are near-zero [06:16] gavin: ok, if the you confirms it's recurring, I'll do that [06:17] oops [06:17] if the user * [06:17] ok [06:17] gavin: thanks [06:19] np [06:22] gavin: do you know about other TB stuff? [06:22] or should I go ask TB-devs [06:24] I have another crash that's a private bugzilla bug [06:25] I know about TB stuff generally [06:25] (or even mozilla stuff generally) [06:25] ok, so there's an Ubuntu crash (2.0.0.23) that matches a windows BT on 3.0b4 [06:25] not an expert on tb specific front-end code, though [06:25] but the bugzilla bug is private and I can't see anything [06:25] what's the mozilla bug? [06:26] (I'm in the mozilla security group) [06:26] mozilla 505221 [06:26] Error: Error getting Mozilla bug #505221: NotPermitted [06:26] that bug is fixed in tb3, waiting for approval for tb2.0.0.x [06:27] gavin: would it be appropriate for me to add it as upstream in LP even though the status can't be seen? [06:27] or will it ever be public? [06:27] I can't comment on LP-appropriateness, I have no idea :) [06:28] gavin: can I assume it'll be made public if/when appropriate [06:28] it will be public once the fix is released to 1.8.1 users or that branch is EOLd, presumably [06:28] yes [06:28] or not at all [06:28] ok, I'll put it in, but in LP it won't be public so I guess it won't matter :) [06:30] gavin: how much of the stacktrace should match for crash matches? [06:31] The top 6 function calls match in this case [06:31] there's no hard-and-fast rule [06:31] that's what asac told me :) [06:31] it's possible for bugs to have different causes with the exact same stack trace [06:32] (though uncommon) [06:32] how about in this casE? [06:33] where's the LP stack trace? [06:33] can I subscribe you to the bug? [06:33] what's your LP nick? [06:34] umm, gavin-sharp I think [06:34] or gavin_sharp? [06:34] https://launchpad.net/~gavin-sharp [06:34] bug 487541 [06:34] Bug 487541 on http://launchpad.net/bugs/487541 is private [06:36] that looks consistent with the bug being fixed in mozilla 505221 [06:36] Error: Error getting Mozilla bug #505221: NotPermitted [06:36] ok gavin, thanks [06:37] gavin: can I ping you if I run into something like this again?> [06:37] sure [06:37] ok, rgeat [06:38] I'm trying to clean up TB bugs in LP before I finish TB3 for Lucid so I can close all the bugs [06:38] gavin: BTW, that bug is fixed in TB3 release or 3.0.1? [06:40] tb3 [06:41] ok, great, that's what I marked [06:44] gavin, regarding mozilla 534663, are the keywords stored in the search engine files? [06:44] Mozilla bug 534663 in Search "[ubuntu] updates overwrite/erases defined keywords for default search engines" [Minor,New] http://bugzilla.mozilla.org/show_bug.cgi?id=534663 [06:44] no [06:44] they're stored in search.sqlite in the profile [06:45] and associated with the plugin using its filename [06:45] gavin: filename or full path? [06:45] filename if in the profile or appdir, full path otherwise [06:46] (in particular, full path for extension-shipped plugins) [06:46] (which AIUI is what ubuntu releases use) [06:47] it's pretty unusual for extension on-disk locations to change [06:47] so the search service doesn't handle that case [06:51] gavin: we actually don't store them directly in the install dir probably for that reason [06:53] for what reason? [06:54] because of the path issues [06:54] we symlink the searchplugins dir in the ff dir [06:54] but they are stored else where [06:55] we store them here: https://bugzilla.mozilla.org/show_bug.cgi?id=534663 [06:55] oops [06:55] Mozilla bug 534663 in Search "[ubuntu] updates overwrite/erases defined keywords for default search engines" [Minor,New] [06:55] we store them here: /usr/lib/firefox-addons/searchplugins/en-US/ [06:56] I'm not sure what "path issues" you're referring to [06:56] the only issues I'm aware of are a result of _not_ storing them in the appdir [06:57] gavin: the moving paths for ff dir in ubuntu [06:58] oh, I see [06:58] you mean that you've tried to work around 534663 by not storing them in the appdir? [06:58] so, is there anything we can do to make the path show where the plugins actually are which doesn't change [06:58] so it seems [07:01] I guess it depends on the location of the extension more than it does the location of the actual plugin files [07:01] though if you're saying that you just symlink them into the app dir, then that theory isn't valid anymore [07:02] gavin: well, I guess the app looks in the app dir...can we have the path resolve the symlink before storing in the sqlite db? [07:03] so that it stores the actual path? [07:03] the problem is the opposite [07:03] we don't want it to store the actual path (since that changes), but it is being saved [07:04] gavin: in Ubuntu, the actual path doesn't change, but the symlink location does [07:04] oh [07:04] where the symlink resolves is constant [07:04] ok I misunderstood - get it now [07:04] that actually makes more sense [07:04] but it's storing the app dir [07:04] (I couldn't figure out why we'd be resolving the symlink) [07:05] but if it's in the appdir, we should only be storing appdir-relative paths [07:05] brb [07:05] which means that this should get fixed after restarts [07:06] which is consistent with the reports in the original bug [07:06] I just assumed the prolem in the ne w bug persisted after restarts [07:06] * gavin 's connection to his irc client is quite laggy for some reason [07:09] gavin: it does [07:09] the problem is after restart the keywords are wiped [07:09] yeah I just saw your comment on the mozilla bug [07:09] clearly I'm not reading these reports closely enough and jumping to conclusions :) [07:10] * micahg is good at that too :) [07:12] gavin: so, is there anything I can do to help with that bug? [07:13] not sure offhand [07:13] only scenario I can think of where that would happen is if the search plugin file name changes [07:14] well, the symlink is APP_DIR/distribution/searchplugins -> /usr/lib/firefox-addons/searchplugins [07:16] should I add these comments to the bugzilla bug [07:21] sure [07:21] I'll have to give this some thought and do some testing [07:21] ok, great, I'll watch for any comments and try to give prompt feedback [07:29] ok gavin, thanks for your help tonight, I must go to sleep now === jtv1 is now known as jtv [11:26] morning [11:45] it's everywhere.. http://www.sofaraway.org/ubuntu/tmp/chrome-ad.png [11:49] lol [11:50] and was that got while using Chrome? [11:50] aahah [12:02] there're two chrome ads in there, one around the page, and one in the banner to give it as a gift to someone else [12:04] gavin: i think this "searchplugin config reset on upgrade bug" is related to the "distribution/..." directory for shipping them (or because we ship them in a lang specific dir) [12:04] (if this is what was talked about above) [12:08] asac, BUGabundo_work: if you want to contribute: http://identi.ca/conversation/17175657#notice-17190196 [12:10] fta: i was positive about moving it to 4am ;) [12:10] ah ;) [12:10] dayfood ;) [12:11] date [12:11] !time [12:11] Information about using and setting your computer's clock on Ubuntu can be found at https://help.ubuntu.com/community/UbuntuTime - See https://help.ubuntu.com/9.04/serverguide/C/NTP.html for information on usage of the Network Time Protocol (NTP) [12:11] !now [12:13] asac, does dayfood match http://www.sofaraway.org/ubuntu/tmp/ppabot-192-192.png ? [12:13] hehe [12:13] most likely not [12:13] spinman ;) [12:14] pushman [12:14] lol [12:14] looks nice ;) [12:14] powerbot [12:14] pushbot [12:14] no idea ;) [12:15] stempify ;) [12:16] what is 12:40 pm? [12:16] is that midnight or lunchtime? [12:16] hmm [12:16] guess lunch [12:19] so far, i like dabot, debot, botronik, drobotik [12:20] asac, http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight [12:20] 12pm is noon [12:21] crazy americans [12:21] great. so its ambiguous [12:21] like 12 a.m. for US government [12:21] otherwise 12 pm ;) [12:26] asac, so, how's chromium on arm now? [12:27] didnt work the last fays [12:27] days [12:27] last build still got snaps/sigills in the browser window with the same probs [12:27] like an infinite backtrace in abort [12:28] seems its badly trashed [12:28] hm [12:29] how come it works fine in chromeos then? [12:29] does chromeos work on arm? [12:29] 'armv7': 1, # Optional, for targeting ARMv7. [12:29] 'arm_thumb': 1, # Optional, for targetting thumb. Combine with armv7 to target thumb2. [12:29] i think we could try just arm_thumb [12:29] and not armv7 [12:30] but thats just another attempt [12:30] unfortunately there is no valgrind etc. [12:30] on arm [12:30] i wanted to try a cross compiled build like on the arm page [12:38] chromeos supports x86 and arm [12:45] fta: are all the testbinaries runnable locally if we build with testsuite? [12:45] fta: maybe we should do that for once again [12:45] and then debug [12:45] yes [12:45] but please add 'arm_thumb': 1, [12:45] 'arm_thumb': 1, # Optional, for targetting thumb. Combine with armv7 to target thumb2. [12:45] if you havent [12:46] hmm already in there [12:47] fta: do we have debug symbols for the testsuite stuff? [12:47] everything is built with -g, so the unstripped binaries (in out/) should be fine [12:48] but it's no longer packaged [12:52] the last arm build was with GYP_DEFINES="target_arch=arm disable_nacl=1 v8_use_snapshot=false linux_use_tcmalloc=0 armv7=1 arm_thumb=1 no_strict_aliasing=1 gcc_version=44 ..." [12:53] fta: no strict aliasing? [12:54] why is gcc_version needed? [12:54] it's set by gcc_version=44 [12:54] well. i see that. but why? [12:54] http://code.google.com/p/chromium/wiki/LinuxChromiumArm [12:54] its not there [12:54] well, i can drop no_strict_aliasing=1 now [12:54] ah [12:54] it was needed for v8 [12:54] thats what you referred to [12:54] but it shouldn't matter for you [12:55] and the gcc_version is still needed? [12:55] shouldnt gyp detect such things? [12:55] yeah [12:55] i need to have a fresh look at the gyp rules [12:55] just checking what is different [12:55] from the arm instructions [12:55] personally i think that a) the chromeos arm thing is built from some branch/tag [12:56] or b) its a toolchain bug for a native build vs. a cross compiler build [12:56] i think a) is more likely as the toolchain is basically the same i guess [13:05] ok, so it seems gcc_version is autodetected now, and that it adds -fno-strict-aliasing & -fno-tree-vrp in v8 when set [13:05] meaning it's not set globally [13:05] i will update the branch accordingly [13:08] done [13:25] fta: chomobot [13:26] it's not dedicated to chrome [13:26] -ium [13:28] fbot ? [13:28] fabbot ? [13:28] fabot? [13:28] bienbot? [13:28] EiffelBuilder? [13:46] hm [13:46] asac, FIREFOX_3_0_17_BUILD1 & FIREFOX_3_5_7_RELEASE [13:47] asac, they too should do continuous releases [13:47] fta: yeah. i think its first jan week [13:47] and yes. thats more or less what they are already doing [13:47] and will move further that way. [13:47] however, their branch procedure is more transparent [13:48] but moving _RELEASE tags are very confusing [13:49] a tag should never move [14:09] fta: yeah. thats a prob. but its a "potential" release tag [14:09] fta: we use system cairo for chrom? [14:11] nope, there's no cairo in there, but skia [14:12] kk [15:35] http://mashable.com/2009/12/20/firefox-popular-browser/ [15:35] FF wininng in Europe [16:43] fta: is there a reason why ff search plugins are in APP_DIR/distribution/searchplugins? [17:09] micahg: yes. thats where distributors are supposed to ship search plugins (main reason). also iirc its the only place where we can ship localized searchplugins [17:09] ah asac, you're back :) [17:10] no ;) [17:10] just checking [17:10] ok, asac, well, when will you be back? [17:11] BOY [17:11] but most likely more active between chris and new y [17:11] i am just gone for like 3 days now? ;) [17:12] yeah, ok, I'm going to try to have TB3 up on review before EOY [17:12] REVU I mean [17:13] asac: ok, so I'll check back with you next Monday [17:13] micahg: no REVU needed [17:13] just let me know when its ready and i upload. we dont even change package names afaik [17:14] asac: ok, I just thought you'd want to look at the changes [17:14] but I guess you can do that in the bzr repo [17:14] micahg: can do that on branch [17:14] its much easier [17:14] yeah [17:14] ok [17:14] micahg: maybe not push to the release branch, but to a topic branch [17:14] so i can look [17:14] try to commit step by step rather than one big chunk [17:14] ok [17:15] i think starting with current thunderbird.dev is fine... the ncopy the current tbird 3.0.head there .... and then change step by step back to the non-versioned approach [17:15] ok, I was going to try some of the documentation on merging bzr branches that was created recently [17:15] I'm also trying to clean up TB bugs so we can close a whole lot with this upload [17:23] micahg: that would be heroic [17:24] I have 23 bugs targeted aleady [17:24] *already [17:25] wow [17:28] they're all fixed upstream :) [17:30] yeah. everything else would be odd ;) (like fixed downstream) [17:31] fta: wheres chromium? http://www.w3schools.com/browsers/browsers_stats.asp [17:56] BUGabundo_work, in Chrome, upstream rejected my patch to expose Chromium (and ubuntu) in the UA [17:56] BUGabundo_work, but those stats are weird, no way IE is at 38% and FF at 47% [17:56] we should patch it still ;) [17:57] we dont want to help contribute to another powerful brand ;) [17:57] at least my opinion [17:58] asac, debian/patches/chromium_useragent.patch is still in the branch [17:58] once folks start to say: "hey, this sucks because its called chromium" then we have failed :) [17:58] asac: ahaha [17:58] or not working in sites like it happens with minefield [17:58] like everyone goes made if you unbrand firefox or ship shiretoko and blame everything on the name [17:59] BUGabundo_work: yeah. but atm lots of sites dont recognize chrome [17:59] so better not help them ;) [17:59] though we are probably not really powerful. but we could ensure that webdesigners that start matching for chrome somehow find out about chromium too [17:59] asac: Hello, I was talking to you 3 weeks ago about building libmozjs from xulrunner-1.9.1, and you said that it would be provided when xulrunner goes to universe, I just checked, and I found that xulrunner *IS* in universe [17:59] so best practices start to match for both [17:59] AnAnt: xulrunner-1.9.1 isnt [18:00] the old stuff is in universe [18:00] but that doesnt help [18:01] asac: oh, you mean xulrunner-1.9.1 at that time then ? [18:01] I don't understand why does it have to be in universe [18:02] I understand that there is an API/ABI incompatability between xulrunner 1.8 & xulrunner 1.9 [18:02] i am not sure about that either (which is why i would prefer to not ship libmozjs at all) .... as this assumes we can break stuff in universe [18:02] in security updates [18:03] http://code.google.com/p/chromium/issues/detail?id=17095 [18:03] or it assumes we can just not provide security updates for universe stuf [18:03] yeah i know about that [18:04] AnAnt: do you understand the point? in short: we cannot backport security fixes for js engine. so once a branch goes EOL we have no choice to abandon it [18:04] which would mean that all folks using libmozjs would be insecur [18:04] e [18:04] http://code.google.com/p/chromium/issues/detail?id=27471 [18:04] if we dont abandon it we need to forwardport everything [18:04] if the branch goes EOL [18:05] what branch goes EOL ? [18:05] 1.8 ? [18:05] sorry, I'm lost [18:06] all branches go EOL [18:06] you have to think about the future [18:07] whatever we put in now will be EOL soon [18:07] atm only 1.9 is EOL. ... beginning next year 1.9 will be EOL and q bit later 1.9.1 [18:07] ok [18:08] so , what's the problem with that ? [18:08] read what i wrote above ;) [18:08] 19:04 < asac> AnAnt: do you understand the point? in short: we cannot backport security fixes for js engine. so once a branch goes EOL we have no choice to abandon it [18:08] 19:04 < asac> which would mean that all folks using libmozjs would be insecur [18:09] EOL End Of Life / Support [18:09] ok, if xulrunner- builds libmozjs, so when 1.9 dies, 1.9.1 will build libmozjs, so what's the problem ? [18:12] AnAnt: libmozjs for 1.9.1 is not compatible with 1.9 mozjs [18:12] so everything that depends on it will break if you just reaplce it [18:12] so it will be libmozjs1 libmozjs2,... [18:13] yes, if you take that approach you just abandon the old branch [18:13] leaving all consumers of the old libmozjs insecure [18:13] well, that won't be the only library doing so [18:14] no other library we have has loads of CVEs open [18:14] in ubuntu we keep libs maintained [18:14] with patches backported [18:14] and dont do library transitions for stable releases [18:14] thats the whole point [18:14] but we cannot do that for libmozjs [18:14] you are welcome to do some excersized [18:14] s [18:15] try to backport all missing CVEs from xul 1.9 to xul 1.8 [18:15] I see, so the problem is that libmozjs has many security issues, that's why you don't want to abandon old libraries, right ? [18:15] ubuntu policy mandates to not abadon anything that is in main [18:16] aha [18:16] for universe its just hearless to do that [18:16] ok, I get it now [18:16] thats why i said that theoretically we can just abandon stuff in universe [18:16] but in practice it would be unfair to do that ... especially if we know up-front that we will end up in this situation [18:17] (if things happen unexpectedly its a bit better ethically) [18:17] thats basically why we also considered to remove xulrunner alltogether [18:17] no xulrunner ... no libs from mozilla [18:17] nothing, but their top-notch apps [18:17] but there are apps using xulrunner [18:18] yes, all those have to die then [18:18] its not nice, but its not our decision [18:19] i fought for years to get mozilla understand that they bust a huge bunch of folks relying on them, but they clearly dont want that and hence, the only thing i can send out to programmers that use xulrunner or libmozjs [18:19] is that they choosed crappy stuff as their base [18:19] ok, I have a question, I understand that Debian give high importance to such security issues, yet they don't take that approach you mention [18:19] asac: btw, is there another option than libmozjs ? [18:19] AnAnt: history is: years ago, there was no security support in debian [18:20] AnAnt: then i stepped up, doing backports, extracing zillion of patches for years [18:20] noone else did it ever [18:20] they will just not provide security support as before [18:20] thats my bet [18:20] they had some conflicts in the past, but couldnt do it and hence didnt do it [18:21] so i think tats where they are heading [18:21] we had long discussions with security team [18:21] etc. [18:21] most likely all xul based apps (incl. libmozjs) cannot go into a stable distribution [18:21] e.g. always unstable only [18:21] i should actually start that discussion again [18:21] asac: btw, is there another option (for developers) than xulrunner & libmozjs ? [18:21] no [18:21] you can go for webkit [18:21] so developers don't have a choice [18:22] but even there our security team is strugeling hard [18:22] it might be a bit better [18:22] I mean, they didn't *choose* crappy stuff [18:22] dont argue with me [18:22] it breaks my hard more than anyones else [18:22] heart [18:23] so webkit supports javascript ? [18:23] AnAnt: atm they need to go to webkit and hope that its all fine [18:23] AnAnt: yes. [18:23] but webkit is fresh and i know its similar painful as mozilla to support ... however, they have a bit more stable API for embedding [18:23] for js i dont know [18:23] v8 (google javascript) has no stable abi/api policy either [18:24] ok, I'll talk with upstreams of software I care about about this webkit, thanks [18:24] so in short: someone needs to step up and support stuff ... most likely target is couchdb project [18:24] which is a well funded project that relies on it [18:24] but only way to convince them is to be harder i think [18:25] they have the attitude: "it will just resolve on its own" [18:25]