| fta | something not negative if possible :P | 00:25 |
|---|---|---|
| fta | or a nickname without bot in it but suiting the avatar | 00:26 |
| fta | no rush, i won't do it tonight | 00:27 |
| === asac_ is now known as asac | ||
| ripps | fta: ppacron? | 02:59 |
| ripps | debcron-bot? | 02:59 |
| === micahg1 is now known as micahg | ||
| === micahg1 is now known as micahg | ||
| micahg | [reed]: what do I do if I have a stacktrace for TB2 that matches one for FF2 that was resolved WFM | 05:54 |
| [reed] | what is it? and what bug? | 06:01 |
| [reed] | do you have STR? | 06:02 |
| micahg | STR? | 06:08 |
| micahg | [reed]: ? | 06:08 |
| gavin | [reed]: ? | 06:09 |
| micahg | bug 488640 and mozilla 361835 | 06:09 |
| ubottu | Bug 488640 on http://launchpad.net/bugs/488640 is private | 06:09 |
| ubottu | 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 |
| micahg | ugh, let me make that TB bug public | 06:09 |
| micahg | ok, it's public now | 06:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| micahg | oops | 06:17 |
| micahg | if the user * | 06:17 |
| gavin | ok | 06:17 |
| micahg | gavin: thanks | 06:17 |
| gavin | np | 06:19 |
| micahg | gavin: do you know about other TB stuff? | 06:22 |
| micahg | or should I go ask TB-devs | 06:22 |
| micahg | I have another crash that's a private bugzilla bug | 06:24 |
| 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:25 |
| gavin | (I'm in the mozilla security group) | 06:26 |
| micahg | mozilla 505221 | 06:26 |
| ubottu | Error: Error getting Mozilla bug #505221: NotPermitted | 06:26 |
| gavin | that bug is fixed in tb3, waiting for approval for tb2.0.0.x | 06:26 |
| 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:27 |
| 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:28 |
| micahg | gavin: how much of the stacktrace should match for crash matches? | 06:30 |
| 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:31 |
| gavin | (though uncommon) | 06:32 |
| micahg | how about in this casE? | 06:32 |
| 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:33 |
| 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:34 |
| ubottu | Bug 487541 on http://launchpad.net/bugs/487541 is private | 06:34 |
| gavin | that looks consistent with the bug being fixed in mozilla 505221 | 06:36 |
| ubottu | Error: Error getting Mozilla bug #505221: NotPermitted | 06:36 |
| micahg | ok gavin, thanks | 06:36 |
| micahg | gavin: can I ping you if I run into something like this again?> | 06:37 |
| gavin | sure | 06:37 |
| micahg | ok, rgeat | 06:37 |
| 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:38 |
| gavin | tb3 | 06:40 |
| micahg | ok, great, that's what I marked | 06:41 |
| micahg | gavin, regarding mozilla 534663, are the keywords stored in the search engine files? | 06:44 |
| ubottu | 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 |
| gavin | no | 06:44 |
| gavin | they're stored in search.sqlite in the profile | 06:44 |
| 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:45 |
| gavin | (in particular, full path for extension-shipped plugins) | 06:46 |
| gavin | (which AIUI is what ubuntu releases use) | 06:46 |
| 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:47 |
| micahg | gavin: we actually don't store them directly in the install dir probably for that reason | 06:51 |
| gavin | for what reason? | 06:53 |
| 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:54 |
| micahg | we store them here: https://bugzilla.mozilla.org/show_bug.cgi?id=534663 | 06:55 |
| micahg | oops | 06:55 |
| ubottu | Mozilla bug 534663 in Search "[ubuntu] updates overwrite/erases defined keywords for default search engines" [Minor,New] | 06:55 |
| micahg | we store them here: /usr/lib/firefox-addons/searchplugins/en-US/ | 06:55 |
| 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:56 |
| micahg | gavin: the moving paths for ff dir in ubuntu | 06:57 |
| 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 | 06:58 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 | |
| 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:09 |
| * micahg is good at that too :) | 07:10 | |
| micahg | gavin: so, is there anything I can do to help with that bug? | 07:12 |
| 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:13 |
| micahg | well, the symlink is APP_DIR/distribution/searchplugins -> /usr/lib/firefox-addons/searchplugins | 07:14 |
| micahg | should I add these comments to the bugzilla bug | 07:16 |
| 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:21 |
| micahg | ok gavin, thanks for your help tonight, I must go to sleep now | 07:29 |
| === jtv1 is now known as jtv | ||
| BUGabundo_work | morning | 11:26 |
| fta | it's everywhere.. http://www.sofaraway.org/ubuntu/tmp/chrome-ad.png | 11:45 |
| BUGabundo_work | lol | 11:49 |
| BUGabundo_work | and was that got while using Chrome? | 11:50 |
| BUGabundo_work | aahah | 11:50 |
| 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:02 |
| 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:04 |
| fta | asac, BUGabundo_work: if you want to contribute: http://identi.ca/conversation/17175657#notice-17190196 | 12:08 |
| asac | fta: i was positive about moving it to 4am ;) | 12:10 |
| asac | ah ;) | 12:10 |
| asac | dayfood ;) | 12:10 |
| asac | date | 12:11 |
| asac | !time | 12:11 |
| ubottu | 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 |
| asac | !now | 12:11 |
| 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:13 |
| 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:14 |
| asac | stempify ;) | 12:15 |
| asac | what is 12:40 pm? | 12:16 |
| asac | is that midnight or lunchtime? | 12:16 |
| asac | hmm | 12:16 |
| asac | guess lunch | 12:16 |
| fta | so far, i like dabot, debot, botronik, drobotik | 12:19 |
| fta | asac, http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight | 12:20 |
| fta | 12pm is noon | 12:20 |
| 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:21 |
| fta | asac, so, how's chromium on arm now? | 12:26 |
| 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:27 |
| asac | seems its badly trashed | 12:28 |
| fta | hm | 12:28 |
| 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:29 |
| 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:30 |
| fta | chromeos supports x86 and arm | 12:38 |
| 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:45 |
| asac | hmm already in there | 12:46 |
| 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:47 |
| fta | but it's no longer packaged | 12:48 |
| 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:52 |
| asac | fta: no strict aliasing? | 12:53 |
| 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:54 |
| 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:55 |
| 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 | 12:56 |
| 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:05 |
| fta | done | 13:08 |
| BUGabundo_work | fta: chomobot | 13:25 |
| fta | it's not dedicated to chrome | 13:26 |
| fta | -ium | 13:26 |
| BUGabundo_work | fbot ? | 13:28 |
| BUGabundo_work | fabbot ? | 13:28 |
| BUGabundo_work | fabot? | 13:28 |
| BUGabundo_work | bienbot? | 13:28 |
| BUGabundo_work | EiffelBuilder? | 13:28 |
| fta | hm | 13:46 |
| fta | asac, FIREFOX_3_0_17_BUILD1 & FIREFOX_3_5_7_RELEASE | 13:46 |
| 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:47 |
| fta | but moving _RELEASE tags are very confusing | 13:48 |
| fta | a tag should never move | 13:49 |
| asac | fta: yeah. thats a prob. but its a "potential" release tag | 14:09 |
| asac | fta: we use system cairo for chrom? | 14:09 |
| fta | nope, there's no cairo in there, but skia | 14:11 |
| asac | kk | 14:12 |
| BUGabundo_work | http://mashable.com/2009/12/20/firefox-popular-browser/ | 15:35 |
| BUGabundo_work | FF wininng in Europe | 15:35 |
| micahg | fta: is there a reason why ff search plugins are in APP_DIR/distribution/searchplugins? | 16:43 |
| 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:09 |
| asac | no ;) | 17:10 |
| asac | just checking | 17:10 |
| micahg | ok, asac, well, when will you be back? | 17:10 |
| 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:11 |
| micahg | yeah, ok, I'm going to try to have TB3 up on review before EOY | 17:12 |
| micahg | REVU I mean | 17:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| asac | micahg: that would be heroic | 17:23 |
| micahg | I have 23 bugs targeted aleady | 17:24 |
| micahg | *already | 17:24 |
| asac | wow | 17:25 |
| micahg | they're all fixed upstream :) | 17:28 |
| asac | yeah. everything else would be odd ;) (like fixed downstream) | 17:30 |
| BUGabundo_work | fta: wheres chromium? http://www.w3schools.com/browsers/browsers_stats.asp | 17:31 |
| 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:56 |
| asac | we dont want to help contribute to another powerful brand ;) | 17:57 |
| asac | at least my opinion | 17:57 |
| 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:58 |
| 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 | 17:59 |
| asac | the old stuff is in universe | 18:00 |
| asac | but that doesnt help | 18:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| AnAnt | what branch goes EOL ? | 18:05 |
| AnAnt | 1.8 ? | 18:05 |
| AnAnt | sorry, I'm lost | 18:05 |
| asac | all branches go EOL | 18:06 |
| asac | you have to think about the future | 18:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| asac | yes, all those have to die then | 18:18 |
| asac | its not nice, but its not our decision | 18:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| asac | its a big mess ;) | 18:27 |
| AnAnt | heard of Simple Ecmascript (SEE) ? | 18:28 |
| 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:29 |
| 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:30 |
| AnAnt | asac: http://www.adaptive-enterprises.com.au/~d/software/see/ | 18:32 |
| asac | 3.0 development status | 18:34 |
| 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:35 |
| === mac_v is now known as vish | ||
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| gavin | I don't recall seeing many new vulnerabilities reported against non-mozilla-supported versions of spidermonkey | 18:49 |
| 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:50 |
| asac | but that didnt even fly for stable branches | 18:51 |
| asac | maybe its all miscommunication | 18:51 |
| asac | if there is a solution to that i am eager to adapt that instantly | 18:52 |
| AnAnt | man, even eclipse uses xulrunner ! | 18:53 |
| asac | yeah | 18:54 |
| asac | they are doomed | 18:54 |
| 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:55 |
| 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:57 |
| 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:58 |
| 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 | 18:59 |
| 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:00 |
| asac | so if i dont vouch for it and security team and archive/release team knowing about it, thing will just die | 19:01 |
| 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:02 |
| 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:03 |
| asac | anyway, shit happens. next year will be a better year i hope :) | 19:04 |
| AnAnt | thanks for the discussion | 19:04 |
| asac | maybe lets hope that after tracemonkey is fast enough things can change ;) | 19:05 |
| AnAnt | tracemonkey ? | 19:05 |
| 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:06 |
| 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:07 |
| 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:09 |
| 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:10 |
| 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:11 |
| asac | they cannot keep up and hence users would be zero-dayed | 19:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| AnAnt | asac: no probs | 19:16 |
| AnAnt | bye | 19:16 |
| micahg | asac: so if upstream will let us put the searchplugins elsewhere, that's ok? | 19:26 |
| 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:31 |
| 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:32 |
| 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:33 |
| micahg | ok, so I can try to work with upstream on this then | 19:34 |
| asac | yes. | 19:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| gavin | simple fix would be to just normalie | 19:40 |
| micahg | gavin: normalize as in realpath? | 19:40 |
| gavin | yes | 19:41 |
| micahg | gavin: ok, should I try to produce a patch? | 19:42 |
| 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:43 |
| 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:44 |
| 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:46 |
| asac | micahg: what do you see in search.sqlite atm? | 19:47 |
| micahg | asac: it shows APP_DIR/distribution/searchplugins/en-US/foo.xml | 19:48 |
| 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:49 |
| asac | so | 19:50 |
| asac | well ... just normalize and since the plcae is stable it should be fine | 19:50 |
| gavin | isInAppDir really should only return true for plugins that are in SrchPlugns (i.e. appdir/searchplugins) | 19:51 |
| asac | yeah | 19:51 |
| 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:52 |
| 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:53 |
| gavin | could do that too I guess | 19:54 |
| asac | which does a startsWith ... match and then used proper [distrosearchdir]/locale/xxxx | 19:54 |
| 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:55 |
| 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:56 |
| 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:58 |
| 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) | 19:59 |
| micahg | should I subscribe linux@distro to the bug? | 20:00 |
| gavin | not sure it's worth spamming everyone watching that? I don't know that this is relevant to any other distros | 20:06 |
| === vish is now known as mac_v | ||
| micahg | gavin: won't it be relavent if we symlink the realpath? | 20:08 |
| micahg | oops | 20:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| asac | also we (plan to) inject localized plugins now through translations ... which are not build in firefox, so same problem for those | 20:12 |
| 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:13 |
| asac | or just normalize after everything has happened in id() ... which is also correct imo | 20:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| asac | asked caillon | 20:23 |
| asac | lets see if he replies | 20:23 |
| gavin | not really limited to linux, though | 20:24 |
| gavin | could be anyone | 20:24 |
| 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:25 |
| 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:30 |
| 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:31 |
| 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:32 |
| asac | gavin: ? | 20:35 |
| gavin | asac: they're used to retrieve/store data from the DB | 20:42 |
| 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 | 20:43 |
| 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:10 |
| 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:11 |
| 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:12 |
| fta | sure, feel free, i won't | 21:13 |
| micahg | I'll copy you and asac | 21:13 |
| micahg | fta: BTW, can you update my address in your addressbook to my ubuntu dot com address? | 21:20 |
| 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:21 |
| fta | want the bot too? | 21:22 |
| micahg | hmm, either way on the bot, since I already set up filters for it | 21:23 |
| BUGabundo | boas o/ | 21:56 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| asac | no | 22:08 |
| asac | subscribe them first | 22:09 |
| asac | then you can ask the question i mentioned | 22:09 |
| micahg | asac: done | 22:10 |
| 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:11 |
| micahg | asac: ok | 22:12 |
| micahg | should I just ping you with notes? | 22:12 |
| asac | yeah | 22:12 |
| 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:13 |
| asac | yeah | 22:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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 | 22:19 |
| === and`_ is now known as and` | ||
| 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:13 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| crimsun | Installed: 4.0.277.0~svn20091219r35045-0ubuntu1~ucd1 | 23:26 |
| fta | 4.0.277.0~svn20091221r35087-0ubuntu1~ucd1~karmic was fine | 23:27 |
| BUGabundo | fta: I don't have Flash on that chromium :D | 23:28 |
| fta | but nothing obvious between r35087 & r35149 | 23:28 |
| micahg | fta: wfm | 23:29 |
| micahg | 4.0.279.0~svn20091222r35149-0ubuntu1~ucd1~karmic | 23:29 |
| fta | micahg, a page with flash? | 23:36 |
| 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:37 |
| micahg | 64 bit | 23:38 |
| fta | BUGabundo, asac: you? | 23:38 |
| asac | 32 | 23:38 |
| 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:39 | |
| 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:40 |
| 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:41 |
| 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:43 |
| micahg | flash crashed, you want the crash report? | 23:44 |
| fta | should not be very helpful, is it? | 23:44 |
| micahg | idk, my guess is no | 23:45 |
| BUGabundo | fta: still opened and going | 23:46 |
| micahg | http://www.downloadsquad.com/2009/12/22/opera-10-5s-new-carakan-javascript-engine-is-fast-google-chro/ | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
