=== bfiller_afk is now known as bfiller [11:36] who decided about this list: https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/extension-list [11:39] bdrung, me [11:39] although other people have looked at it too [11:40] chrisccoulson: why can bugmail-extension stay, but pwdhash has to go. both work, but pwdhash has six times more users [11:40] s/\./?/ [11:40] oh, bugmail-extensions could probably go too tbh [11:41] and downloadstatusbar? [11:41] bindwood? [11:42] bdrung, bindwood is canonical maintained and we don't ship a xpi file for that [11:42] extensions that aren't easily installable from a.m.o stay [11:42] Why shouldn't extensions that are easily installable from a.m.o also stay? [11:42] and downloadstatusbar is incredibly popular and well maintained [11:43] persia - we're trimming down the extensions in preparation for how we're supporting firefox in the future [11:43] chrisccoulson: popcon stat = 18? [11:44] bdrung -that's only because it appeared in the archive this cycle. i'm also using figures on a.m.o too, and downloadstatusbar is currently at 27,978,689 [11:44] versus 91,532 for pwdhash [11:44] Well, OK. I'm philosophically against the concept of encouraging folks to install anything from anywhere other than the repos, but if it won't be maintained otherwise, it makes sense. [11:45] persia - the issue is that it's going to be difficult and time consuming to maintain these in 4 supported releases moving forwards [11:45] persia - this explains everything - https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/ [11:45] You're against Firefox users installing extensions from its own addons site? [11:45] Mitch: Yes. [11:45] chrisccoulson: i still think that pwdhash should stay - it's maintained by me and isn't easy installable from a.m.o atm [11:45] chrisccoulson: I understand. It doesn't mean I like it. It's a matter of not having an infinite number of maintainers. [11:45] * bdrung agrees with persia. [11:46] * Mitch scratches head [11:46] bdrung, why is it not easily installable from a.m.o? i even provided a link to the xpi on the wiki page [11:46] chrisccoulson: you have to edit install.rdf to allow FF 3.6 [11:48] Mitch: this is an example why a debian package is better ^ [11:48] bdrung - well, it works here from a.m.o [11:49] and i disagree there. i'm sure if you looked at all the extensions on a.m.o, you will find plenty of them with various problems which mean they don't work properly, but that's not a good reason to package them in our archive [11:49] in fact, i think that's a good reason *not* to package them [11:49] chrisccoulson: "PwdHash 1.7 konnte nicht installiert werden, da es nicht kompatibel mit Firefox 3.6.3 ist." - not compatible with FF 3.6.3 [11:49] bdrung: You can't always bump the maxVersion and expect it to work. [11:49] bdrung - well, i just installed it from there and it's working fine [11:50] Mitch: i know, but in this case the extension needs no modification [11:50] chrisccoulson: with FF 3.6? [11:50] bdrung - yes [11:51] chrisccoulson: It's a philosophical thing: my packaging it, we can patch it to work, and provide some expectation to users that it should work. By not packaging popular stuff, we encourage users to pull from other sources, which may spread to e.g. PPAs, and cause systems to become unstable through no fault of our own. [11:51] chrisccoulson: but why does mine FF complain about it? [11:52] persia - i've deliberately tried to keep some of the most popular extensions though [11:52] we just want to keep the number to a mimimum so we don't have to spend ages fixing them each time we update firefox in the stable release [11:53] chrisccoulson: you agree, that this issue is a lack of manpower? [11:53] we can't have extensions blocking firefox updates, and users won't be happy if we update firefox and break all their extensions until we find the time to fix them all [11:54] bdrung - yes, but the answer is not increasing manpower [11:54] chrisccoulson: Like I said, I understand, I'm just opposed. To me the right solution is for firefox to have a sane release model. :) [11:54] persia - agreed, but that is beyond our control [11:55] and it's the same support model that chromium will be using too [11:55] that is never going to change unfortunately, so we just have to adapt our processes to that [11:55] I thought that was still being hotly debated. [11:55] which bit was being debated? [11:55] At least chromium doesn't have the annoying "you can't patch this without our approval" restriction. [11:56] The chromium support model. [11:56] chrisccoulson: really? we can release a new version of FF and it will break the extensions downloaded from e.m.o and the users will be unhappy, too [11:56] But anyway, I'm dragging you off-topic, on to something I don't wish to debate, as it's long been decided :) [11:56] i'm not that familiar with chromium, but i don't think they're going to adopt the model that mozilla have been using all this time [11:56] bdrung - but those will be updated faster than the ones in our archive [11:56] Chromium != Google Chrome. [11:57] Mitch, i know ;) [11:57] They're not letting anyone use their name either. [11:57] chrisccoulson: only if we lack manpower. e.g. pwdhash is updated in the archive earlier [11:57] This is OK though, because it's true for *every* distribution. [11:59] bdrung - why would pwdhash be updated in the archive earlier? we definately don't want to be spending efforts porting extensions ourselves each time there is a firefox update [12:00] and if you're saying that pwdhash will be slow to be ported, then that really isn't a good argument for keeping it in the archive anyway [12:00] chrisccoulson: because i updated it. [12:01] bdrung - so, if pwdhash was in the archive, you would be able to guarantee to support this on all 4 stable releases plus the development release? [12:01] chrisccoulson: yes [12:02] chrisccoulson: i am using it on a daily basis - i have an incentive to have a working version of it [12:02] ok, well, maybe we could keep that one then. but i'm not going to start adding lots of extensions back just because people have a preference for them [12:03] otherwise we would still end up with an archive full of random extensions ;) [12:03] Which ought be fine, if we have sufficient maintainers. === BUGabundo is now known as BUGa_vacations [12:10] morning [12:11] On a completely different topic, does anyone happen to know how the localised search providers hook referenced in bug #526411 works? [12:11] Launchpad bug 526411 in ubufox "In a fresh installation, firefox search engines are ordered alphabetically" [High,Fix released] https://launchpad.net/bugs/526411 [12:17] persia - good question, i will try and find that out [12:17] chrisccoulson: That'd be great. English Yahoo fails miserably for Japan, and we'd like to use yahoo.jp at least. [12:18] persia - oh, ok. so, you're actually asking for a locale specific search URL instead? [12:18] Yeah. Based on the changes, I *think* it can be set in the langpack, but I just can't find any docs on what settings are needed. [12:19] yeah, i'm not too sure how to provide localised search plugins at the moment [12:22] chrisccoulson: do you want to keep livehttpheaders if it's updated? [12:23] bdrung - i'm indifferent about that one. it seems quite popular according to popcon, so i'm ok with keeping that if it gets updated [12:24] chrisccoulson: a.m.o shows 2 M downloads. sage-extension (low popcon due to new package) has 2.5 M downloads. the question is where to make the cut [12:25] bdrung - tbh, those are all borderline really. for consistency, we should probably srop livehttpheaders (it doesn't really fall in the category of the really popular extensions like adblock and greasemonkey [12:26] s/srop/drop [12:26] agreed [12:27] noscript needs updating too, and that is one that we should keep around [12:29] chrisccoulson: i'll update greasemonkey - to short the todo list [12:29] bdrung, thanks [12:37] chrisccoulson: the install.rdf from webdeveloper says maxVersion 3.5 [12:37] bdrung - yeah, micahg thinks that was changed in debian, as that's different to the upstream version [12:38] chrisccoulson: nope. upstream is the same - look into the xpi file from e.m.o [12:39] chrisccoulson: it's the same issue as pwdhash. e.m.o says that it works with FF 3.6, but the install.rdf says max version = 3.5 [12:43] now i'm confused :-/ [12:43] :) [12:44] chrisccoulson: greasemonkey uploaded [12:44] thanks [12:47] chrisccoulson: btw, look at http://chrispederick.com/work/web-developer/history/ -> No FF 3.6 mentioned [13:00] asac: around? [13:22] !info closure-compiler [13:23] Package closure-compiler does not exist in lucid [14:22] BUGabundo, http://www.tijuana.fr/wp-content/uploads/2008/11/groupe-suricate.jpg [14:24] hihih [14:33] who's volunteering to package closure-compiler? [14:33] debian 555683 [14:33] Debian bug 555683 in wnpp "ITP: closure-compiler -- JavaScript optimizing compiler" [Wishlist,Open] http://bugs.debian.org/555683 [14:56] Hello. Do you know of a thunderbird with enigmail bug where the pinentry window sometimes does not get displayed and TB gets stuck waiting in lucid? === yofel_ is now known as yofel === ubott2 is now known as ubottu [21:07] hi, anyone using googles toolbar with firefox?- can i get favicons in the favorites? === Mitch_ is now known as Mitch === Mitch_ is now known as Mitch [21:28] \o [21:33] http://www.youtube.com/watch?v=lAl28d6tbko === Mitch_ is now known as Mitch === Mitch_ is now known as Mitch [22:23] chrisccoulson: regarding pwdhash, upstream is very responsive. i wrote a mail today and got a response hours later. upstream knew that pwdhash works with FF 3.6. so he bumped the version via e.m.o (that's the reason that you see FF 3.6 support there) === hggdh_ is now known as hggdh === Mitch_ is now known as Mitch === Mitch_ is now known as Mitch