[00:25] <fta> something not negative if possible :P
[00:26] <fta> or a nickname without bot in it but suiting the avatar
[00:27] <fta> no rush, i won't do it tonight
[02:59] <ripps> fta: ppacron?
[02:59] <ripps> debcron-bot?
[05:54] <micahg> [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] <micahg> STR?
[06:08] <micahg> [reed]: ?
[06:09] <gavin> [reed]: ?
[06:09] <micahg> bug 488640 and mozilla 361835
[06:09] <micahg> ugh, let me make that TB bug public
[06:11] <micahg> ok, it's public now
[06:12] <micahg> 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] <gavin> assume it was fixed? :)
[06:13] <gavin> upgrade to tb3?
[06:13]  * gavin is kidding
[06:13] <gavin> not sure what context you're asking in
[06:14] <micahg> well, can I move to TB and reopen?
[06:14] <micahg> or should I file another bug in TB?
[06:14] <micahg> I started searching crash-stats.mozilla.com for crash reports
[06:14] <micahg> that's how I found it
[06:15] <gavin> well, it's unlikely that the problem would be fixed in tb2 unless it's very serious
[06:15] <gavin> given that 1.8 has been almost entirely abandoned
[06:15] <gavin> (especially now that tb3 is out)
[06:15] <micahg> gavin: ok, I'll ask the user if it's persistent or a one time thing
[06:16] <gavin> you 'd probably want to file a new TB bug, mark it 1.8 only, and reference 361835
[06:16] <gavin> but like I said, odds of it being fixed are near-zero
[06:16] <micahg> gavin: ok, if the you confirms it's recurring, I'll do that
[06:17] <micahg> oops
[06:17] <micahg> if the user *
[06:17] <gavin> ok
[06:17] <micahg> gavin: thanks
[06:19] <gavin> np
[06:22] <micahg> gavin: do you know about other TB stuff?
[06:22] <micahg> or should I go ask TB-devs
[06:24] <micahg> I have another crash that's a private bugzilla bug
[06:25] <gavin> I know about TB stuff generally
[06:25] <gavin> (or even mozilla stuff generally)
[06:25] <micahg> ok, so there's an Ubuntu crash (2.0.0.23) that matches a windows BT on 3.0b4
[06:25] <gavin> not an expert on tb specific front-end code, though
[06:25] <micahg> but the bugzilla bug is private and I can't see anything
[06:25] <gavin> what's the mozilla bug?
[06:26] <gavin> (I'm in the mozilla security group)
[06:26] <micahg> mozilla 505221
[06:26] <gavin> that bug is fixed in tb3, waiting for approval for tb2.0.0.x
[06:27] <micahg> gavin: would it be appropriate for me to add it as upstream in LP even though the status can't be seen?
[06:27] <micahg> or will it ever be public?
[06:27] <gavin> I can't comment on LP-appropriateness, I have no idea :)
[06:28] <micahg> gavin: can I assume it'll be made public if/when appropriate
[06:28] <gavin> it will be public once the fix is released to 1.8.1 users or that branch is EOLd, presumably
[06:28] <gavin> yes
[06:28] <micahg> or not at all
[06:28] <micahg> ok, I'll put it in, but in LP it won't be public so I guess it won't matter :)
[06:30] <micahg> gavin: how much of the stacktrace should match for crash matches?
[06:31] <micahg> The top 6 function calls match in this case
[06:31] <gavin> there's no hard-and-fast rule
[06:31] <micahg> that's what asac told me :)
[06:31] <gavin> it's possible for bugs to have different causes with the exact same stack trace
[06:32] <gavin> (though uncommon)
[06:32] <micahg> how about in this casE?
[06:33] <gavin> where's the LP stack trace?
[06:33] <micahg> can I subscribe you to the bug?
[06:33] <micahg> what's your LP nick?
[06:34] <gavin> umm, gavin-sharp I think
[06:34] <gavin> or gavin_sharp?
[06:34] <gavin> https://launchpad.net/~gavin-sharp
[06:34] <micahg> bug 487541
[06:36] <gavin> that looks consistent with the bug being fixed in mozilla 505221
[06:36] <micahg> ok gavin, thanks
[06:37] <micahg> gavin: can I ping you if I run into something like this again?>
[06:37] <gavin> sure
[06:37] <micahg> ok, rgeat
[06:38] <micahg> 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] <micahg> gavin: BTW, that bug is fixed in TB3 release or 3.0.1?
[06:40] <gavin> tb3
[06:41] <micahg> ok, great, that's what I marked
[06:44] <micahg> gavin, regarding mozilla 534663, are the keywords stored in the search engine files?
[06:44] <gavin> no
[06:44] <gavin> they're stored in search.sqlite in the profile
[06:45] <gavin> and associated with the plugin using its filename
[06:45] <micahg> gavin: filename or full path?
[06:45] <gavin> filename if in the profile or appdir, full path otherwise
[06:46] <gavin> (in particular, full path for extension-shipped plugins)
[06:46] <gavin> (which AIUI is what ubuntu releases use)
[06:47] <gavin> it's pretty unusual for extension on-disk locations to change
[06:47] <gavin> so the search service doesn't handle that case
[06:51] <micahg> gavin: we actually don't store them directly in the install dir probably for that reason
[06:53] <gavin> for what reason?
[06:54] <micahg> because of the path issues
[06:54] <micahg> we symlink the searchplugins dir in the ff dir
[06:54] <micahg> but they are stored else where
[06:55] <micahg> we store them here: https://bugzilla.mozilla.org/show_bug.cgi?id=534663
[06:55] <micahg> oops
[06:55] <micahg> we store them here: /usr/lib/firefox-addons/searchplugins/en-US/
[06:56] <gavin> I'm not sure what "path issues" you're referring to
[06:56] <gavin> the only issues I'm aware of are a result of _not_ storing them in the appdir
[06:57] <micahg> gavin: the moving paths for ff dir in ubuntu
[06:58] <gavin> oh, I see
[06:58] <gavin> you mean that you've tried to work around 534663 by not storing them in the appdir?
[06:58] <micahg> so, is there anything we can do to make the path show where the plugins actually are which doesn't change
[06:58] <micahg> so it seems
[07:01] <gavin> I guess it depends on the location of the extension more than it does the location of the actual plugin files
[07:01] <gavin> though if you're saying that you just symlink them into the app dir, then that theory isn't valid anymore
[07:02] <micahg> 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] <micahg> so that it stores the actual path?
[07:03] <gavin> the problem is the opposite
[07:03] <gavin> we don't want it to store the actual path (since that changes), but it is being saved
[07:04] <micahg> gavin: in Ubuntu, the actual path doesn't change, but the symlink location does
[07:04] <gavin> oh
[07:04] <micahg> where the symlink resolves is constant
[07:04] <gavin> ok I misunderstood - get it now
[07:04] <gavin> that actually makes more sense
[07:04] <micahg> but it's storing the app dir
[07:04] <gavin> (I couldn't figure out why we'd be resolving the symlink)
[07:05] <gavin> but if it's in the appdir, we should only be storing appdir-relative paths
[07:05] <micahg> brb
[07:05] <gavin> which means that this should get fixed after restarts
[07:06] <gavin> which is consistent with the reports in the original bug
[07:06] <gavin> 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] <micahg> gavin: it does
[07:09] <micahg> the problem is after restart the keywords are wiped
[07:09] <gavin> yeah I just saw your comment on the mozilla bug
[07:09] <gavin> clearly I'm not reading these reports closely enough and jumping to conclusions :)
[07:10]  * micahg is good at that too :)
[07:12] <micahg> gavin: so, is there anything I can do to help with that bug?
[07:13] <gavin> not sure offhand
[07:13] <gavin> only scenario I can think of where that would happen is if the search plugin file name changes
[07:14] <micahg> well, the symlink is APP_DIR/distribution/searchplugins -> /usr/lib/firefox-addons/searchplugins
[07:16] <micahg> should I add these comments to the bugzilla bug
[07:21] <gavin> sure
[07:21] <gavin> I'll have to give this some thought and do some testing
[07:21] <micahg> ok, great, I'll watch for any comments and try to give prompt feedback
[07:29] <micahg> ok gavin, thanks for your help tonight, I must go to sleep now
[11:26] <BUGabundo_work> morning
[11:45] <fta> it's everywhere.. http://www.sofaraway.org/ubuntu/tmp/chrome-ad.png
[11:49] <BUGabundo_work> lol
[11:50] <BUGabundo_work> and was that got while using Chrome?
[11:50] <BUGabundo_work> aahah
[12:02] <fta> 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] <asac> 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] <asac> (if this is what was talked about above)
[12:08] <fta> asac, BUGabundo_work: if you want to contribute: http://identi.ca/conversation/17175657#notice-17190196
[12:10] <asac> fta: i was positive about moving it to 4am ;)
[12:10] <asac> ah ;)
[12:10] <asac> dayfood ;)
[12:11] <asac> date
[12:11] <asac> !time
[12:11] <asac> !now
[12:13] <fta> asac, does dayfood match http://www.sofaraway.org/ubuntu/tmp/ppabot-192-192.png ?
[12:13] <asac> hehe
[12:13] <asac> most likely not
[12:13] <asac> spinman ;)
[12:14] <asac> pushman
[12:14] <asac> lol
[12:14] <asac> looks nice ;)
[12:14] <asac> powerbot
[12:14] <asac> pushbot
[12:14] <asac> no idea ;)
[12:15] <asac> stempify ;)
[12:16] <asac> what is 12:40 pm?
[12:16] <asac> is that midnight or lunchtime?
[12:16] <asac> hmm
[12:16] <asac> guess lunch
[12:19] <fta> so far, i like dabot, debot, botronik, drobotik
[12:20] <fta> asac, http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight
[12:20] <fta> 12pm is noon
[12:21] <fta> crazy americans
[12:21] <asac> great. so its ambiguous
[12:21] <asac> like 12 a.m. for US government
[12:21] <asac> otherwise 12 pm ;)
[12:26] <fta> asac, so, how's chromium on arm now?
[12:27] <asac> didnt work the last fays
[12:27] <asac> days
[12:27] <asac> last build still got snaps/sigills in the browser window with the same probs
[12:27] <asac> like an infinite backtrace in abort
[12:28] <asac> seems its badly trashed
[12:28] <fta> hm
[12:29] <fta> how come it works fine in chromeos then?
[12:29] <asac> does chromeos work on arm?
[12:29] <asac> 'armv7': 1, # Optional, for targeting ARMv7.
[12:29] <asac> 'arm_thumb': 1, # Optional, for targetting thumb.  Combine with armv7 to target thumb2.
[12:29] <asac> i think we could try just arm_thumb
[12:29] <asac> and not armv7
[12:30] <asac> but thats just another attempt
[12:30] <asac> unfortunately there is no valgrind etc.
[12:30] <asac> on arm
[12:30] <asac> i wanted to try a cross compiled build like on the arm page
[12:38] <fta> chromeos supports x86 and arm
[12:45] <asac> fta: are all the testbinaries runnable locally if we build with testsuite?
[12:45] <asac> fta: maybe we should do that for once again
[12:45] <asac> and then debug
[12:45] <fta> yes
[12:45] <asac> but please add 'arm_thumb': 1,
[12:45] <asac> 'arm_thumb': 1, # Optional, for targetting thumb.  Combine with armv7 to target thumb2.
[12:45] <asac> if you havent
[12:46] <asac> hmm already in there
[12:47] <asac> fta: do we have debug symbols for the testsuite stuff?
[12:47] <fta> everything is built with -g, so the unstripped binaries (in out/) should be fine
[12:48] <fta> but it's no longer packaged
[12:52] <fta> 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] <asac> fta: no strict aliasing?
[12:54] <asac> why is gcc_version needed?
[12:54] <fta> it's set by gcc_version=44
[12:54] <asac> well. i see that. but why?
[12:54] <asac> http://code.google.com/p/chromium/wiki/LinuxChromiumArm
[12:54] <asac> its not there
[12:54] <fta> well, i can drop no_strict_aliasing=1 now
[12:54] <asac> ah
[12:54] <fta> it was needed for v8
[12:54] <asac> thats what you referred to
[12:54] <fta> but it shouldn't matter for you
[12:55] <asac> and the gcc_version is still needed?
[12:55] <asac> shouldnt gyp detect such things?
[12:55] <asac> yeah
[12:55] <fta> i need to have a fresh look at the gyp rules
[12:55] <asac> just checking what is different
[12:55] <asac> from the arm instructions
[12:55] <asac> personally i think that a) the chromeos arm thing is built from some branch/tag
[12:56] <asac> or b) its a toolchain bug for a native build vs. a cross compiler build
[12:56] <asac> i think a) is more likely as the toolchain is basically the same i guess
[13:05] <fta> 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] <fta> meaning it's not set globally
[13:05] <fta> i will update the branch accordingly
[13:08] <fta> done
[13:25] <BUGabundo_work> fta: chomobot
[13:26] <fta> it's not dedicated to chrome
[13:26] <fta> -ium
[13:28] <BUGabundo_work> fbot ?
[13:28] <BUGabundo_work> fabbot ?
[13:28] <BUGabundo_work> fabot?
[13:28] <BUGabundo_work> bienbot?
[13:28] <BUGabundo_work> EiffelBuilder?
[13:46] <fta> hm
[13:46] <fta> asac, FIREFOX_3_0_17_BUILD1 & FIREFOX_3_5_7_RELEASE
[13:47] <fta> asac, they too should do continuous releases
[13:47] <asac> fta: yeah. i think its first jan week
[13:47] <asac> and yes. thats more or less what they are already doing
[13:47] <asac> and will move further that way.
[13:47] <asac> however, their branch procedure is more transparent
[13:48] <fta> but moving _RELEASE tags are very confusing
[13:49] <fta> a tag should never move
[14:09] <asac> fta: yeah. thats a prob. but its a "potential" release tag
[14:09] <asac> fta: we use system cairo for chrom?
[14:11] <fta> nope, there's no cairo in there, but skia
[14:12] <asac> kk
[15:35] <BUGabundo_work> http://mashable.com/2009/12/20/firefox-popular-browser/
[15:35] <BUGabundo_work> FF wininng in Europe
[16:43] <micahg> fta: is there a reason why ff search plugins are in APP_DIR/distribution/searchplugins?
[17:09] <asac> 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] <micahg> ah asac, you're back :)
[17:10] <asac> no ;)
[17:10] <asac> just checking
[17:10] <micahg> ok, asac, well, when will you be back?
[17:11] <asac> BOY
[17:11] <asac> but most likely more active between chris and new y
[17:11] <asac> i am just gone for like 3 days now? ;)
[17:12] <micahg> yeah, ok, I'm going to try to have TB3 up on review before EOY
[17:12] <micahg> REVU I mean
[17:13] <micahg> asac: ok, so I'll check back with you next Monday
[17:13] <asac> micahg: no REVU needed
[17:13] <asac> just let me know when its ready and i upload. we dont even change package names afaik
[17:14] <micahg> asac: ok, I just thought you'd want to look at the changes
[17:14] <micahg> but I guess you can do that in the bzr repo
[17:14] <asac> micahg: can do that on branch
[17:14] <asac> its much easier
[17:14] <asac> yeah
[17:14] <micahg> ok
[17:14] <asac> micahg: maybe not push to the release branch, but to a topic branch
[17:14] <asac> so i can look
[17:14] <asac> try to commit step by step rather than one big chunk
[17:14] <micahg> ok
[17:15] <asac> 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] <micahg> ok, I was going to try some of the documentation on merging bzr branches that was created recently
[17:15] <micahg> I'm also trying to clean up TB bugs so we can close a whole lot with this upload
[17:23] <asac> micahg: that would be heroic
[17:24] <micahg> I have 23 bugs targeted aleady
[17:24] <micahg> *already
[17:25] <asac> wow
[17:28] <micahg> they're all fixed upstream :)
[17:30] <asac> yeah. everything else would be odd ;) (like fixed downstream)
[17:31] <BUGabundo_work> fta: wheres chromium? http://www.w3schools.com/browsers/browsers_stats.asp
[17:56] <fta> BUGabundo_work, in Chrome, upstream rejected my patch to expose Chromium (and ubuntu) in the UA
[17:56] <fta> BUGabundo_work, but those stats are weird, no way IE is at 38% and FF at 47%
[17:56] <asac> we should patch it still ;)
[17:57] <asac> we dont want to help contribute to another powerful brand ;)
[17:57] <asac> at least my opinion
[17:58] <fta> asac, debian/patches/chromium_useragent.patch is still in the branch
[17:58] <asac> once folks start to say: "hey, this sucks because its called chromium" then we have failed :)
[17:58] <BUGabundo_work> asac: ahaha
[17:58] <BUGabundo_work> or not working in sites like it happens with minefield
[17:58] <asac> like everyone goes made if you unbrand firefox or ship shiretoko and blame everything on the name
[17:59] <asac> BUGabundo_work: yeah. but atm lots of sites dont recognize chrome
[17:59] <asac> so better not help them ;)
[17:59] <asac> 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] <AnAnt> 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] <asac> so best practices start to match for both
[17:59] <asac> AnAnt: xulrunner-1.9.1 isnt
[18:00] <asac> the old stuff is in universe
[18:00] <asac> but that doesnt help
[18:01] <AnAnt> asac: oh, you mean xulrunner-1.9.1 at that time then ?
[18:01] <AnAnt> I don't understand why does it have to be in universe
[18:02] <AnAnt> I understand that there is an API/ABI incompatability between xulrunner 1.8 & xulrunner 1.9
[18:02] <asac> 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] <asac> in security updates
[18:03] <fta> http://code.google.com/p/chromium/issues/detail?id=17095
[18:03] <asac> or it assumes we can just not provide security updates for universe stuf
[18:03] <asac> yeah i know about that
[18: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:04] <asac> which would mean that all folks using libmozjs would be insecur
[18:04] <asac> e
[18:04] <fta> http://code.google.com/p/chromium/issues/detail?id=27471
[18:04] <asac> if we dont abandon it we need to forwardport everything
[18:04] <asac> if the branch goes EOL
[18:05] <AnAnt> what branch goes EOL ?
[18:05] <AnAnt> 1.8 ?
[18:05] <AnAnt> sorry, I'm lost
[18:06] <asac> all branches go EOL
[18:06] <asac> you have to think about the future
[18:07] <asac> whatever we put in now will be EOL soon
[18:07] <asac> atm only 1.9 is EOL. ... beginning next year 1.9 will be EOL and q bit later 1.9.1
[18:07] <AnAnt> ok
[18:08] <AnAnt> so , what's the problem with that ?
[18:08] <asac> read what i wrote above ;)
[18:08] <asac> 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] <asac> 19:04 < asac> which would mean that all folks using libmozjs would be insecur
[18:09] <BUGabundo_work> EOL End Of Life / Support
[18:09] <AnAnt> ok, if xulrunner-<version> builds libmozjs, so when 1.9 dies, 1.9.1 will build libmozjs, so what's the problem ?
[18:12] <asac> AnAnt: libmozjs for 1.9.1 is not compatible with 1.9 mozjs
[18:12] <asac> so everything that depends on it will break if you just reaplce it
[18:12] <AnAnt> so it will be libmozjs1 libmozjs2,...
[18:13] <asac> yes, if you take that approach you just abandon the old branch
[18:13] <asac> leaving all consumers of the old libmozjs insecure
[18:13] <AnAnt> well, that won't be the only library doing so
[18:14] <asac> no other library we have has loads of CVEs open
[18:14] <asac> in ubuntu we keep libs maintained
[18:14] <asac> with patches backported
[18:14] <asac> and dont do library transitions for stable releases
[18:14] <asac> thats the whole point
[18:14] <asac> but we cannot do that for libmozjs
[18:14] <asac> you are welcome to do some excersized
[18:14] <asac> s
[18:15] <asac> try to backport all missing CVEs from xul 1.9 to xul 1.8
[18:15] <AnAnt> 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] <asac> ubuntu policy mandates to not abadon anything that is in main
[18:16] <AnAnt> aha
[18:16] <asac> for universe its just hearless to do that
[18:16] <AnAnt> ok, I get it now
[18:16] <asac> thats why i said that theoretically we can just abandon stuff in universe
[18:16] <asac> 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] <asac> (if things happen unexpectedly its a bit better ethically)
[18:17] <asac> thats basically why we also considered to remove xulrunner alltogether
[18:17] <asac> no xulrunner ... no libs from mozilla
[18:17] <asac> nothing, but their top-notch apps
[18:17] <AnAnt> but there are apps using xulrunner
[18:18] <asac> yes, all those have to die then
[18:18] <asac> its not nice, but its not our decision
[18:19] <asac> 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] <asac> is that they choosed crappy stuff as their base
[18:19] <AnAnt> 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] <AnAnt> asac: btw, is there another option than libmozjs ?
[18:19] <asac> AnAnt: history is: years ago, there was no security support in debian
[18:20] <asac> AnAnt: then i stepped up, doing backports, extracing zillion of patches for years
[18:20] <asac> noone else did it ever
[18:20] <asac> they will just not provide security support as before
[18:20] <asac> thats my bet
[18:20] <asac> they had some conflicts in the past, but couldnt do it and hence didnt do it
[18:21] <asac> so i think tats where they are heading
[18:21] <asac> we had long discussions with security team
[18:21] <asac> etc.
[18:21] <asac> most likely all xul based apps (incl. libmozjs) cannot go into a stable distribution
[18:21] <asac> e.g. always unstable only
[18:21] <asac> i should actually start that discussion again
[18:21] <AnAnt> asac: btw, is there another option (for developers) than xulrunner & libmozjs ?
[18:21] <asac> no
[18:21] <asac> you can go for webkit
[18:21] <AnAnt> so developers don't have a choice
[18:22] <asac> but even there our security team is strugeling hard
[18:22] <asac> it might be a bit better
[18:22] <AnAnt> I mean, they didn't *choose* crappy stuff
[18:22] <asac> dont argue with me
[18:22] <asac> it breaks my hard more than anyones else
[18:22] <asac> heart
[18:23] <AnAnt> so webkit supports javascript ?
[18:23] <asac> AnAnt: atm they need to go to webkit and hope that its all fine
[18:23] <asac> AnAnt: yes.
[18:23] <asac> 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] <asac> for js i dont know
[18:23] <asac> v8 (google javascript) has no stable abi/api policy either
[18:24] <AnAnt> ok, I'll talk with upstreams of software I care about about this webkit, thanks
[18:24] <asac> so in short: someone needs to step up and support stuff ... most likely target is couchdb project
[18:24] <asac> which is a well funded project that relies on it
[18:24] <asac> but only way to convince them is to be harder i think
[18:25] <asac> they have the attitude: "it will just resolve on its own"
[18:25] <AnAnt> couchdb ? isn't that a database thing ?
[18:25] <asac> thats a javascript based database ... yes.
[18:25] <asac> you write stored procedures in javascript or something
[18:25] <asac> also it uses json
[18:25] <asac> etc.
[18:25] <asac> its the only app in main that we have that uses mozjs
[18:25] <asac> which causes me to cry every day ;)
[18:25] <asac> that it exists
[18:27] <asac> its a big mess ;)
[18:28] <AnAnt> heard of Simple Ecmascript (SEE) ?
[18:29] <asac> nope ... new?
[18:29] <asac> i think the right approach would be to provide a stable, minimal wrapper lib around mozjs/v8 etc. that is then eagerly maintained accross mozjs/v8 branches
[18:29] <AnAnt> well, elinks supports SEE backend, but I dunno what it is
[18:30] <asac> but someone needs to do that ;)
[18:30] <asac> AnAnt: if you find the upstream source for that i would love to take a look
[18:30] <asac> or even package if there is any
[18:32] <AnAnt> asac: http://www.adaptive-enterprises.com.au/~d/software/see/
[18:34] <asac> 3.0 development status
[18:35] <asac> Only a single active developer
[18:35] <asac> Decreasing year-over-year development activity
[18:35] <gavin> asac: "bust a huge bunch of folks" has a much different cost valuation for us than it does for you, I think
[18:35] <gavin> need to put "huge" is put into context - by far the largest libmozjs userbase is official firefox release users, not users of libmozjs in ubuntu
[18:36] <asac> gavin: yes.
[18:36] <gavin> that's not to say that we should be cavalier about dropping support, either, but it seems like you often seem to dismiss the cost of maintaining these old releases too easily
[18:37] <asac> gavin: i am not saying i dont understand the reasoning.
[18:37] <asac> just saying that the situation is sad
[18:37] <asac> but i see the point "why should you do it"
[18:37] <asac> its just that mozilla as a foundation/charity
[18:37] <asac> might be the single only entity that would listen for the ecosystem
[18:37] <asac> and invest even though it doesnt give a benefit
[18:37] <asac> just "to make the web a better place"
[18:37] <asac> ;M)
[18:38] <gavin> well, I think part of the problem there is that we disagree about what would be the most effective way to "make the web a better place"
[18:38] <asac> yeah
[18:38] <gavin> we have limited resources, and the thinking is that innovating and moving faster is actually more effective than maintaining support
[18:38] <asac> well. it might also be "what is the web"
[18:39] <asac> gavin: yes. its a tradeoff. but the argument is always: "someone else should do the stable maintenance" ... which obviously doesnt work, because the only folks that could do it are employed by mozilla ;)(
[18:39] <asac> gavin: but i also see its unfair to put the burden of being slow/uninnovative
[18:39] <asac> on mozilla ... while others are ok to do what they want
[18:39] <asac> (e.g. v8 namely)
[18:39] <gavin> yeah
[18:40] <asac> its just that you were the only folks being good
[18:40] <asac> (well never as good as it could be;))
[18:40] <asac> but you were the only ones providing that stuff
[18:40] <asac> so thats why folks got pissed.
[18:40] <asac> and now they move to webkit, which doesnt help at all here ;)
[18:42] <AnAnt> asac: sorry again, but what's the problem of webkit ?
[18:42] <gavin> people sometimes do tend to feel entitled to a free lunch :)
[18:42] <asac> gavin: but also, its unfair to say that "we want to freeride when we ask for this"; yes, it sucks that there is innovative stuff we cannot support, but mostly it breaks my heart to go to free software developers and tell them : "sorry, but using mozembed or mozjs is just a no go ... and there is nothing else i can tell you to use, just enjoy your spare time rather than developing"
[18:42] <asac> anyway, i hvae reached the point to accept that
[18:43] <asac> now i just have to somehow get all mozilla consumers out of the archive ;)
[18:43] <asac> AnAnt: webkit has no track record of security
[18:43] <gavin> I guess I don't understand why you have to tell them not to use mozjs
[18:43] <asac> so its like saying: "its not great in europe, lets go to the unknown land"
[18:44] <asac> gavin: no stable ABI/API guarantees - not even on stable branches.
[18:44] <asac> i talked to jorendorff a bit in the past talking about a minimal subset
[18:44] <gavin> it seems to me like you make stability garantees that aren't actually useful in practice
[18:45] <asac> that could be kept stable
[18:45] <asac> gavin: well. if users use libmozjs ... and there is ABI/API breakage in a security update, its not usable
[18:45] <asac> and evne if there is the risk of that
[18:45] <gavin> (or that have a high cost/benefit ratio)
[18:45] <asac> also we have to move t your new approach of rolling major versions
[18:46] <asac> gavin: libs need to provide a stable API ... consider gtk+ busting you every other year
[18:46] <asac> thats a bigger scale of course, but for apps that heavily rely on mozjs api, its probably the same as gtk+ brekaing for you
[18:47] <gavin> yeah, I recognize the value of stable APIs
[18:47] <[reed]> gtk+ does bust us
[18:47] <asac> right. what i was trying to say is if there is not even a minimal subset of mozjs api we know is stable, i can only say to mozjs consumers that they cannot be supported in the distro
[18:47] <[reed]> we've found numerous gtk+ bugs
[18:47] <[reed]> it's ridiculously hard to get them fixed upstream
[18:47] <gavin> but it's not like old versions of libmozjs disappear - they just stop getting frequent updates
[18:47] <asac> [reed]: well. bugs are != ABI/API breakage
[18:48] <gavin> if people are not able to move to new api versions, they always have the ability to stay on the old version, and deal with those issues instead
[18:48] <asac> gavin: they dont get security updates. and with about 30% of CVEs going for js its not supportable
[18:48] <gavin> right, but the security issues couldv ery well be easier to deal with than the compat-switching issues
[18:48] <gavin> (or not worth dealing with at all)
[18:49] <gavin> I don't recall seeing many new vulnerabilities reported against non-mozilla-supported versions of spidermonkey
[18:50] <asac> gavin: where are those "non-mozilla-supported" versions of spidermonkey? ... that was basically what we asked for
[18:50] <asac> and got turned down
[18:50] <asac> we wanted to build mozjs with special flags to just export a minimal API, so apps can at least have some mozjs.
[18:51] <asac> but that didnt even fly for stable branches
[18:51] <asac> maybe its all miscommunication
[18:52] <asac> if there is a solution to that i am eager to adapt that instantly
[18:53] <AnAnt> man, even eclipse uses xulrunner !
[18:54] <asac> yeah
[18:54] <asac> they are doomed
[18:55] <AnAnt> wow !
[18:55] <asac> the other plan (besides the deliberatly making universe insecure) was to remove everything that depends on it in archive
[18:57] <AnAnt> but if you tend to keep mozilla apps without the libs (and I see that those apps depend on xulrunner too), then that means that each app will have a copy of xulrunner with it
[18:57] <asac> which is probably what will happen (because security team and archive admins understand the current situatioN)
[18:57] <asac> AnAnt: yes. thats the only support model feasible
[18:58] <asac> and that also means, that only the most important apps are allowed in
[18:58] <asac> (with an exceptioN)
[18:58] <asac> so basically it blocks all xulrunner apps, but firefox/thunderbird
[18:58] <asac> from entering the archive
[18:58] <AnAnt> you mean the main archive or even universe ?
[18:58] <asac> or just ignore it and deliberaly allow universe users to use hot/insecure stuff
[18:58] <asac> AnAnt: arguably there is no difference from main and universe
[18:59] <asac> users use it
[18:59] <asac> why would you deliberately allow users of universe software to be exploitablke
[18:59] <asac> that causes massive headaches if you know it up-front
[19:00] <asac> personally, i feel really bad about all this, because it felt important for me to strengthen the mozilla ecosystem
[19:00] <asac> but i cannot strengthen it without mozilla wanting it (which was discussed as a somewhat reasonalbe decision for mozilla to not do)
[19:01] <asac> so if i dont vouch for it and security team and archive/release team knowing about it, thing will just die
[19:02] <asac> also ubuntu tries to be a great distribution, but in the end we understand ourselves as a distribution platform
[19:02] <asac> especially for universe etc.
[19:02] <asac> if someone tells us repeatedly thats not appreciated then there is no point pushing in the other direction.
[19:02] <asac> it only causes discussions like this one ;)
[19:03] <asac> in two years, when everyone has accepted that its normal to have no mozembed in the world, then all will be better and chances are even higher that a valid replacement appears
[19:04] <asac> anyway, shit happens. next year will be a better year i hope :)
[19:04] <AnAnt> thanks for the discussion
[19:05] <asac> maybe lets hope that after tracemonkey is fast enough things can change ;)
[19:05] <AnAnt> tracemonkey ?
[19:06] <asac> but i wouldnt wait for it ... developers at least like it more if they dont need to have a stable API
[19:06] <asac> tracemonkey == mozjs with jit
[19:06] <AnAnt> oh, another mozilla product
[19:06] <asac> i think its the same product
[19:06] <AnAnt> ok
[19:07] <asac> its not a product btw ;)
[19:07] <asac> its a secondary/assistive project currently existing to power firefox ... thats why we have these issues
[19:09] <AnAnt> ok, I need to understand something, in case xulrunner gets removed from Ubuntu. An application like eclipse (if it bundles xulrunner with it) will need an exception to get into universe ?
[19:09] <AnAnt> or the exception is for main ?
[19:09] <asac> i think its more likely that eclipse needs to get the parts patched out
[19:09] <asac> that use xulrunner
[19:09] <asac> its really just a minor use case where they use it
[19:09] <AnAnt> ok, eclipse was just an example
[19:10] <asac> but in theory yes
[19:10] <asac> if an app needs xulrunner, it cannot enter the archive until it proofed to be essential
[19:10] <asac> which is a bit hard if its not in the archive of course
[19:10] <asac> but thats how it is ;)
[19:10] <asac> like if firefox would be less popular we could drop it
[19:10] <asac> and would
[19:10] <asac> same for tbird ;)
[19:11] <asac> but thats a bit extreme
[19:11] <asac> basically, as long as we are sure that upstream including xulrunner keeps up with the security fixes, it can stay in
[19:11] <asac> however, thats probably just firefox
[19:11] <asac> and thunderbird maybe
[19:11] <AnAnt> ok
[19:11] <asac> things like songbird etc. did never enter the archive because of that
[19:12] <asac> they cannot keep up and hence users would be zero-dayed
[19:13] <AnAnt> asac: do you know wether Debian would make such a similar decision ?
[19:13] <asac> if i raise this, i am quite sure that security folks will agree and make this happen, yes.
[19:13] <asac> havent started discussing that with them
[19:14] <asac> in the past i was the only guy preventing such a move
[19:14] <asac> e.g. it owuld have happened for etch and lenny if i hadnt promissed that we can do it somehow
[19:15] <asac> but now i cannot promiss that anymore, because upstream model is getting even more aggressive
[19:15] <asac> i will probably also approach redhat and suse about this
[19:15] <AnAnt> asac: thanks again for this discussion
[19:15] <AnAnt> I'll need to run now
[19:15] <asac> no problem. sorry that i cannot give better perspective
[19:16] <AnAnt> asac: no probs
[19:16] <AnAnt> bye
[19:26] <micahg> asac: so if upstream will let us put the searchplugins elsewhere, that's ok?
[19:31] <asac> micahg: not sure
[19:31] <asac> i dont think that will help
[19:31] <asac> whats the problem?
[19:31] <micahg> asac: in upstream builds, they're in APP_DIR/searchplugins
[19:31] <asac> yes, but that doesnt work
[19:31] <micahg> the problem seems to be the way it's stored in the search.slite
[19:31] <asac> for locale specific stuff
[19:31] <micahg> *search.sqlite
[19:31] <asac> yes, i guessed so
[19:32] <asac> i think we need to normalize the path its stored under
[19:32] <micahg> I was going to do some test builds to see if that would help
[19:32] <micahg> asac: well, the plugins are actually stored outside the app_dir as I"m sure you know
[19:32] <asac> micahg: i think it helps, but localization is not working at that place afaict
[19:32] <asac> micahg: so?
[19:32] <asac> its just a link
[19:33] <asac> we have them in APP_DIR/distribution/searchplugins/...
[19:33] <micahg> asac: yeah, but one option might be to resolve the symlink before storing in sqlite
[19:33] <asac> yes, thats what i mean
[19:33] <asac> 20:31 < asac> i think we need to normalize the path its stored under
[19:33] <asac> first run a realpath
[19:33] <asac> then store it
[19:33] <asac> maybe its done for the APP_DIR/searchplugins place atm
[19:33] <micahg> oh, I thought you meant normalize the app_dir path :)
[19:33] <asac> then its a bug for the distribution/searchplugins
[19:33] <asac> no ;)
[19:34] <micahg> ok, so I can try to work with upstream on this then
[19:34] <asac> yes.
[19:35] <asac> most important requirement is a) that its locale sensitive
[19:35] <micahg> asac: would you prefer the realpath solution to moving the search dir?
[19:35] <asac> moving where?
[19:35] <asac> maybe its really a bug even for APP_DIR/searchplugins
[19:35] <micahg> so that it is recognized as [app]/foo.xml
[19:35] <asac> try that out
[19:36] <micahg> ok, I'll try that
[19:36] <asac> you mean APP/searchplugins/foox.mk?
[19:36] <asac> we need locale support
[19:36] <micahg> no, it would be [app]/locale/foo.xml
[19:36] <asac> they dont hvae that in upstream builds; and afair i moved it to distributions/ directory because of that
[19:36] <micahg> upstream [app] is firefox/searchplugins
[19:36] <asac> micahg: APP/searchplugins/locale/foox.mk you mean?
[19:36] <asac> ah
[19:36] <asac> well
[19:36] <micahg> in the sqlite db :)
[19:37] <asac> thats more or less ok, but in the end the distribution directory should work
[19:37] <micahg> ok, gavin wasn't familiar with our dir structure
[19:40] <gavin> simple fix would be to just normalie
[19:40] <micahg> gavin: normalize as in realpath?
[19:41] <gavin> yes
[19:42] <micahg> gavin: ok, should I try to produce a patch?
[19:43] <gavin> sure
[19:43] <gavin> http://mxr.mozilla.org/mozilla-central/source/toolkit/components/search/nsSearchService.js#2786
[19:43] <gavin> |file| is an nsIFile
[19:43] <gavin> you could check isSymlink() and then use .target, perhaps
[19:43] <gavin> or maybe just call normalize()
[19:44] <gavin> yeah, normalize() seems to realpath()
[19:44] <gavin> http://mxr.mozilla.org/mozilla-central/source/xpcom/io/nsLocalFileUnix.cpp#530
[19:44] <asac> right. should be simple enough
[19:44] <micahg> gavin: ok,  I'll try tonight :)
[19:44] <asac> thx
[19:46] <asac> i am not sure if isSymlink returns true if any of the ancestors is a symlink. you could also just say "normalize"
[19:46] <asac> if its right its right and if not it shouldnt hurt
[19:47] <asac> micahg: what do you see in search.sqlite atm?
[19:48] <micahg> asac: it shows APP_DIR/distribution/searchplugins/en-US/foo.xml
[19:49] <asac> es, i think the problem is not the follwo symlink, but rather the
[19:49] <asac> isInAppDir test
[19:49] <asac> that should make a substring match
[19:50] <asac> so
[19:50] <asac> well ... just normalize and since the plcae is stable it should be fine
[19:51] <gavin> isInAppDir really should only return true for plugins that are in SrchPlugns (i.e. appdir/searchplugins)
[19:51] <asac> yeah
[19:52] <asac> but wouldnt work with localization either
[19:52] <gavin> otherwise there could be conflicts (since two plugins could have the same file name in appdir/ and appdir/distribution)
[19:52] <asac> but i think that location doesnt support locales
[19:52] <gavin> right, it doesn't
[19:52] <gavin> it could, but there isn't really any reason to given that distribution already exists
[19:52] <gavin> (once we fix this bug anyways)
[19:53] <asac> yes
[19:53] <asac> gavin: though the normalize fix is a bit of a hack ... for us we have a stable realpath for the plugins
[19:53] <asac> but if we would ship it just below the real app dir it wouldnt help
[19:53] <gavin> yeah
[19:53] <asac> so we would need to add something like isBelowDistroDir...
[19:54] <gavin> could do that too I guess
[19:54] <asac> which does a startsWith ... match and then used proper [distrosearchdir]/locale/xxxx
[19:55] <gavin> the problem is that there are a bunch of places that can be in SrchPluginsDL
[19:55] <asac> but then we could just do "isBelowAppDir" in the same way
[19:55] <asac> for everything
[19:55] <gavin> and it's kind of ugly to have to hardcode checks for all of them
[19:56] <gavin> yeah, maybe that would be better
[19:56] <asac> but then the current [app] thing would be required for legacy i guess
[19:56] <asac> otherwise it wouldnt match as [app] = APP/searchplugins
[19:56] <gavin> indeed
[19:56] <asac> hmm
[19:58] <gavin> it wouldn't be too hard to move to using e.g. [appdir] for all things under the appdir, but still use [app] for APP/searchplugins specifically
[19:58] <asac> so not sure. maybe the normalize is the right way to move forward - but it might break other distros that ship their app with a link
[19:58] <asac> yeah
[19:58] <asac> thts what i ment
[19:58] <asac> prefer [app]
[19:58] <asac> if that works
[19:58] <asac> its fine
[19:58] <asac> otherwise try [appdir] on the full path
[19:58] <asac> but the whole code uses leafName ;)
[19:59] <asac> hmm. seems to be just id
[19:59] <asac> that should be managable
[19:59] <gavin> yeah, it just needs to be unique
[19:59] <gavin> (for a given file)
[20:00] <micahg> should I subscribe linux@distro to the bug?
[20:06] <gavin> not sure it's worth spamming everyone watching that? I don't know that this is relevant to any other distros
[20:08] <micahg> gavin: won't it be relavent if we symlink the realpath?
[20:08] <micahg> oops
[20:09] <micahg> realpath the symlink?
[20:09] <gavin> maybe, but I don't know that that's common either
[20:09] <asac> micahg: we shouldnt do that imo.
[20:09] <gavin> yeah, maybe we jsut shouldn't do that
[20:09] <asac> some distros ship their app in a non versioned path
[20:09] <asac> but others do
[20:09] <asac> and i would guess they use a symlink like us
[20:10] <asac> if not distribution ... they symlink searchplugins
[20:10] <asac> so normalize would break
[20:10] <asac> we should go for the appdir approach
[20:10] <asac> hmm
[20:11] <gavin> why do you symlink search plugins, btw?
[20:11] <asac> i think we might get around by normalizing here:
[20:11] <asac> http://mxr.mozilla.org/mozilla-central/source/toolkit/components/search/nsSearchService.js#2297
[20:11] <asac> e.g. after all the other stuff failed
[20:11] <asac> gavin: because otherwise they are in a versioned directory, so we cannot ship additional plugins from outside
[20:11] <asac> without breaking those on updates
[20:12] <asac> also we (plan to) inject localized plugins now through translations ... which are not build in firefox, so same problem for those
[20:13] <micahg> ok, so should I try to add an [app_dir[ check there?
[20:13] <asac> micahg: yes. add a simliar function: isBelowAppDir ... or something and then dont use leafName for those matching that, but substring
[20:15] <asac> or just normalize after everything has happened in id() ... which is also correct imo
[20:16] <micahg> asac: gavin: does it matter that AppDir isn't being used consistently in the functions?
[20:16] <asac> micahg: yes.
[20:16] <asac> we hvae appsearchdir ... thats the current APP
[20:16] <asac> we would have appdir ... thats the real appdir
[20:16] <micahg> isInAppDir is APP_DIR/searchplugins where isBelowAppDir would be APP_DIR
[20:17] <micahg> asac: how about isInDistroAppDir?
[20:17] <asac> yes ... and for the Below you wouldnt implement a ==, but a startsWith
[20:17] <gavin> isInAppDir is a bit of a misuse of "app dir"
[20:17] <gavin> it's really "app searchplugins dir"
[20:17] <micahg> right, that's what I'm asking about
[20:17] <asac> micahg: ther emight be more dirs etc., so adding checks for each possible location was considered a scalability problem
[20:17] <gavin> you can use appdir.contains(file, true)
[20:17] <asac> thats why i think isBelowAppDir is best we can do to extend this for noce and for all
[20:18] <gavin> but I just thought of something... switching to [appdir] will mean we'll change the IDs of existing plugins
[20:18] <asac> gavin: contains does a recursive search?
[20:18] <gavin> asac: that's the second param
[20:18] <asac> gavin: thats what i said, we should keep app
[20:19] <gavin> asac: not just app, though
[20:19] <asac> and prefer that ... and then go for appdir
[20:19] <asac> if it didnt match
[20:19] <gavin> there are existing plugins that fall back to using the full path as their ID
[20:19] <gavin> if we make them now use [appdir]/path, their ID will change
[20:19] <asac> gavin: hmm. ok. so we need to do appdistrosearch ;)
[20:20] <gavin> I guess we could limit it to that case, yeah
[20:20] <asac> great. but we need recursive search too, because of the locale/common dir in between
[20:20] <micahg> ok, once you two figure it out, please tell me what to try  :)
[20:20] <gavin> but we'd still have that problem for people who were using the distro dir but without the symlnik
[20:20] <asac> gavin: why?
[20:20] <asac> ah
[20:20] <asac> well.
[20:20] <gavin> because we'd still be changing their IDs
[20:21] <gavin> not a big deal in the ubuntu case since that's already happening (due to this bug)
[20:21] <asac> yeah. thats collateral damage ;)
[20:21] <asac> we might want to subscribe linux.bugs to figure if anyone uses distribution dir then ;)
[20:22] <asac> i can ping caillon directly to check redhat
[20:22] <asac> debian doesnt use it for sure.
[20:22] <asac> and wolfr i can ask i guess
[20:23] <asac> asked caillon
[20:23] <asac> lets see if he replies
[20:24] <gavin> not really limited to linux, though
[20:24] <gavin> could be anyone
[20:25] <asac> hmm
[20:25] <asac> so caillon said no.
[20:25] <asac> but you are right
[20:25] <asac> so lets bread a bit further  on this ;)
[20:30] <asac> sucky
[20:30] <asac> distro patch ;)?
[20:30] <asac> hehe
[20:30] <asac> or migration
[20:30] <gavin> normalize() is sounding like a better option now
[20:31] <gavin> only downside is that it's kind of hacky and non-obvious, right?
[20:31] <gavin> less likely to cause compat issues, I think
[20:31] <asac> yes. also as you said it might change id for those that have a symlink but are not affected
[20:32] <asac> atm
[20:32] <asac> personally, i would consider that likelyhood low
[20:32] <gavin> right
[20:32] <asac> where are the ids compared?
[20:32] <asac> is that __id thing something special?
[20:35] <asac> gavin: ?
[20:42] <gavin> asac: they're used to retrieve/store data from the DB
[20:43] <gavin> http://mxr.mozilla.org/mozilla-central/source/toolkit/components/search/nsSearchService.js#3494
[20:43] <asac> hmm. ok. that doesnt give much flexibility to do smart stuff
[21:10] <micahg> fta: I would think throwing the files up to a bzr repo under his user in LP would be easiest
[21:10] <fta> ?
[21:10] <micahg> fta: re the seammonkey email
[21:10] <fta> oh
[21:11] <fta> we already have a sm2 branch
[21:11] <fta> i just orphaned it a while ago
[21:11] <micahg> fta: right, but we can see his changes and take what works
[21:11] <fta> yep, it was not clear to me if he said he had a package or just the control file
[21:12] <micahg> fta: well, I don't think anyone's agreed to do it yet, I have a note for myself If I have time
[21:12] <micahg> fta: would you like me to reply to him?
[21:13] <fta> sure, feel free, i won't
[21:13] <micahg> I'll copy you and asac
[21:20] <micahg> fta: BTW, can you update my address in your addressbook to my ubuntu dot com address?
[21:21] <fta> sure, send me an email with it
[21:21] <fta> nm, jsut got one
[21:21] <micahg> fta: thanks :), otherwise, that stuff can get lost in my bugmail :)
[21:22] <fta> want the bot too?
[21:23] <micahg> hmm, either way on the bot, since I already set up filters for it
[21:56] <BUGabundo> boas o/
[22:02] <asac> hi BUGabundo
[22:02] <BUGabundo> Olá Alexander
[22:02] <BUGabundo> ... the great
[22:02] <micahg> asac: did you ever figure out what I should try w/regard to the search plugin stuff
[22:02] <asac> micahg: can you subscribe stransky at redhat.com and caillon at redhat.com to the distribution bug?
[22:02] <fta> asac, today's chromium is snaping
[22:02] <fta> http://paste.ubuntu.com/344968/
[22:03] <micahg> asac: on bmo?
[22:03] <asac> micahg: yes
[22:03] <asac> fta: sigh
[22:03] <asac> fta: so you dont track the green takgs?
[22:03] <fta> green as in "it builds"
[22:04] <asac> hmm. thought it also includes that the tests run
[22:04] <asac> and dont crash etc.
[22:04] <micahg> asac: dine
[22:04] <micahg> oops
[22:04] <micahg> done
[22:04] <asac> k
[22:04] <asac> micahg: wolfgang rosenauer is the opensuse guy we should subscribe
[22:04] <asac> but i dont know his email in bugzilla atm
[22:04] <asac> only know his nick: wolfr
[22:04] <asac> but he probably is subscribed to a bunch of other linux bugs
[22:05] <asac> especially the kde integration one ;)
[22:05] <micahg> but we don't want to just do linux@distro?
[22:05] <micahg> asac: found it
[22:05] <asac> micahg: definitly subscribe them individually too ...
[22:06] <micahg> asac: I should also add linux@distro?
[22:06] <asac> micahg: not before we propose a solution imo
[22:06] <micahg> do I need to comment when adding them?
[22:07] <asac> hmm ... maybe subscribe it ... and afdter that ask if anyone uses distribution/searchplugins
[22:07] <asac> micahg: yes.
[22:07] <asac> you need to just hit enter if you are in the CC field
[22:07] <asac> or just say commit
[22:07] <micahg> asac: no, I mean do I need to say why I'm subscribing them?
[22:08] <asac> no
[22:09] <asac> subscribe them first
[22:09] <asac> then you can ask the question i mentioned
[22:10] <micahg> asac: done
[22:11] <asac> micahg: in case they have questions or something where i need to provide input let me know. i probably will miss all mail till jan
[22:12] <micahg> asac: ok
[22:12] <micahg> should I just ping you with notes?
[22:12] <asac> yeah
[22:13] <micahg> asac: as long as I have you here, debian source format 3, we probably won't do that till Hardy is EOL on desktop, right?
[22:14] <asac> yeah
[22:15] <asac> our packages need to work everywhere
[22:15] <micahg> asac: also, should I try to bump TB3 to debian standards 3.8.3?
[22:15] <asac> why not ;)
[22:15] <micahg> ok, but any debhelper stuff needs to work on hardy, right?
[22:16] <asac> micahg: did you figure a sensible way to merge the tb 3.head branch onto the tbird.dev one?
[22:16] <asac> micahg: right.
[22:16] <micahg> asac: well, there's some docs on merging branches since that'll be the new way to merge from debian, I was going to try that
[22:16] <asac> i think we should try to keep the approaches for tibrd/xul/ffox simliar
[22:17] <asac> micahg: you can try. but the problem here is that there is no common ancestor
[22:17] <asac> if that doc helps great
[22:17] <micahg> asac: worse possible case, I'll do it by hand, but I don't think that'll be necessary
[22:19] <asac> nah. i think you can do bzr merge -r 0.. /path/to/tbird3.0.head
[22:19] <asac> hopefully
[22:19] <asac> maybe remoivng the files that are not in the tb3 branch first
[23:13] <fta> asac, can't find a commit that could have done this. other option is the strict aliasing thing i changed in the branch
[23:22] <asac> maybe a flash update ;)?
[23:22] <fta> BUGabundo, you're using the chromium hardy builds right?
[23:22] <asac> BUGabundo on hardy?
[23:22] <fta> on debian
[23:22] <asac> ah
[23:22] <asac> lenny or what?
[23:23] <BUGabundo> fta: yep
[23:23] <fta> just want to try that, the gcc44 thing was obviously not used on hardy
[23:23] <BUGabundo> on debian? hardy on unstable
[23:24] <fta> BUGabundo, could you upgrade chromium to the lastest (where you're using the hardy ppa) and try a page with flash
[23:24] <BUGabundo> fta: tomorrow
[23:24] <BUGabundo> at work
[23:24] <BUGabundo> I do daily updates
[23:24] <BUGabundo> ping me then
[23:24] <fta> :(
[23:24] <BUGabundo> at home, I have lucid
[23:25] <fta> too late then, i will revert and rebuild
[23:25] <BUGabundo> okay
[23:25] <fta> 4.0.279.0~svn20091222r35149-0ubuntu1~ucd1~karmic is broken with flash apparently
[23:26] <crimsun> Installed: 4.0.277.0~svn20091219r35045-0ubuntu1~ucd1
[23:27] <fta> 4.0.277.0~svn20091221r35087-0ubuntu1~ucd1~karmic was fine
[23:28] <BUGabundo> fta: I don't have Flash on that chromium :D
[23:28] <fta> but nothing obvious between r35087 & r35149
[23:29] <micahg> fta:  wfm
[23:29] <micahg> 4.0.279.0~svn20091222r35149-0ubuntu1~ucd1~karmic
[23:36] <fta> micahg, a page with flash?
[23:37] <micahg> fta: yep, after a few refreshes, hulu and youtube work
[23:37] <fta> strange, i also tried with a fresh profile
[23:37] <fta> 32 or 64?
[23:38] <micahg> 64 bit
[23:38] <fta> BUGabundo, asac: you?
[23:38] <asac> 32
[23:39] <BUGabundo> fta: ?
[23:39] <BUGabundo> 64bits
[23:39] <fta> so 32 snaps and 64 doesn't?
[23:39] <BUGabundo> flash 64bits
[23:39] <BUGabundo> .so
[23:39] <fta> it's not flash itself, it's the renderer
[23:39]  * micahg is using adobe flash
[23:40] <fta> me too
[23:40] <fta> unfortunately
[23:40] <BUGabundo> fta: just tested youtube
[23:40] <BUGabundo> works ok with up to date chromium
[23:40] <BUGabundo> and what ever flash I have
[23:41] <fta> i can't load www.lemonde.fr for ex
[23:41] <BUGabundo> Shockwave Flash 10.0 r42
[23:41] <BUGabundo> testing
[23:41] <BUGabundo> WFM
[23:41] <BUGabundo> even with flash block
[23:41] <fta> ok so it's a 32bit issue
[23:41] <fta> the revert sounds nicer
[23:43] <micahg> fta: I can't load that site either
[23:43] <micahg> wait, it just worked
[23:43] <fta> it should load, then snap
[23:43] <fta> just that tab
[23:44] <micahg> flash crashed, you want the crash report?
[23:44] <fta> should not be very helpful, is it?
[23:45] <micahg> idk, my guess is no
[23:46] <BUGabundo> fta: still opened and going
[23:48] <micahg> http://www.downloadsquad.com/2009/12/22/opera-10-5s-new-carakan-javascript-engine-is-fast-google-chro/