[04:15] hi all. I'm with the marketing team and we could use a little help with a marketing project involving a firefox plugin [04:16] the Italian team has a plug in that adds a custom links menu = kinda like the ubuntu plug in [04:17] and we were wamting to design one for the marketing team which the locos could use to access marketing materials [04:18] we could use some help with the coding [04:19] our maybe just point us to tutorials we can read, some sort of howto.... [09:21] bug 240028 [09:21] Launchpad bug 240028 in language-pack-es-base "Problem in language-pack-es-base order installation makes Firefox translations lost" [Undecided,New] https://launchpad.net/bugs/240028 [10:37] Hello everybody :) [10:37] asac: It works! :-) [10:37] Yannig: cool :) [10:37] Well, I have a valid xpi Occitan translation installed [10:37] I'd just need to know how to have it used by Firefox now :p [10:37] Yannig: ;) ... not finish translation and we can include it. [10:38] Yannig: as i said: LANG=es_ES firefox [10:38] would make firefox start in spanish [10:38] replace es_ES with you lang code [10:38] so maybe [10:38] Where should I write that? [10:38] LANG=oc firefox [10:38] in the terminal :) [10:39] It should already be done: I have Ubuntu in Occitan :p [10:39] echo $LANG [10:39] ? [10:39] what does that yield? [10:39] oc_FR.UTF-8 [10:39] further paste your chrome.manifest [10:39] in the .xpi [10:40] Yannig: you need two xpis: firefox + xulrunner [10:40] do you have both? [10:40] Nope :p [10:40] without xulrunner its unlikely to work [10:40] create that one too [10:40] 1. get the en-US.xpi from the ubutu language tarball ... and then go ahead like usual [10:41] That's it, done [10:42] chrome.manifest: [10:42] locale branding firefox_oc jar:firefox-firefox_oc.jar!/locale/branding/ [10:42] locale browser-region firefox_oc jar:firefox-firefox_oc.jar!/locale/browser-region/ [10:42] locale browser firefox_oc jar:firefox-firefox_oc.jar!/locale/browser/ [10:43] Yannig: thats wrong [10:43] hmm [10:43] most likely because you used the firefox_oc.po ? [10:43] Yep [10:43] i guess you have to rename it to be just oc.po [10:43] Should I rename it? [10:44] (without firefox_) [10:44] yes [10:44] i should look into how to fix that [10:44] or oc-FR.po? [10:44] Yannig: just strip off firefox_ from the file you get from launchpad [10:44] same for xulrunner_ [10:45] xulrunner.po, that's right for it [10:45] no [10:45] stripp it off [10:45] usually i have firefox/de.po [10:45] and xulrunner/de.po [10:45] :) [10:46] e.g. each have their own directory (like in the langpack tarball) [10:46] Ops [10:48] ./runpo2xpi xulrunner en-US.xpi xulrunner.po => I now have a Firefox (Xulrunner) extension in my add-ons [10:48] (and a Firefox (oc) too) [10:49] ./runpo2xpi xulrunner en-US.xpi de.po [10:49] thats what i would call [10:49] xulrunner.po wont work (as i said above) [10:50] Ops x 2 [10:51] It works :) [10:51] My Firefox is now in Occitan :) [10:51] Thanks asac :) [10:51] Yannig: ok [10:51] Yannig: now for QA [10:51] Yannig: take care that your keyboard shortcuts work properly [10:52] I just have to go on translating now, for I'm pretty far away from the end :p [10:52] ilike alt+f opens the file menu in english [10:52] and other latin languages [10:52] you need something similar (unless you want the english bindings, then you should not translate them at all) [10:53] otherwise, just go ahead and translate :) [10:53] let me know when you are finished ;) [10:53] "finished"? [10:53] Snirf :D [10:53] hehe [10:53] Well, at work now :-) [10:53] yeah [10:54] i guess it will take a few days to translate ;) [10:54] It encourages me much more than Mozilla translation policy :-) [10:54] Alone, perhaps more than a few days :p [10:54] yeah take your time [10:55] Yannig: where is the mozilla translation policy document? [10:55] No idea [10:55] For then, you have to have all finished to have a CVS account [10:55] then => them [10:55] ah [10:55] ok [10:55] we can work on that here then ;) [10:55] and once finished, push up [10:56] Yep :) [10:56] Yannig: if you are in this channel i'll ping you once i have improved the po2xpi scripts ... which obviously can be improved alot :) [10:57] Fair enough [10:57] well ... they are not really ment for testing yet ;) [10:57] but work if you follow the rules :) [11:01] That's it... [11:18] Tell me asac... [11:18] Should Thunderbird be translatable in the same way one day? [11:19] Yannig: yes [11:19] Great :-) [11:19] for now we just do firefox. once the launchpad tools are completely ready (e.g. exports .xpi directly) we will make more application available in it [11:20] if ther eis demand and in case this wont happenin time for intrepid we could make it available anyway [11:44] I loooooooove Launchpad :) [11:49] Yannig: dont you prefer http://qa.debian.org/ :) [11:49] is it me or it's down very often ? [11:50] No idea, I can't open the page :p [11:51] moi non plus [13:28] Nothing can be perfect :P [13:28] XML Parsing Error: undefined entity [13:28] Location: chrome://browser/content/browser.xul [13:28] Line Number 34, Column 1: ^ [13:28] asac: Any idea of how to fix that? :p [13:32] you have a typo in some translation [13:32] canet tell without looking [13:32] where do you get that? thought it worked a bit alreaady [13:33] I have it when I try to open Firefox :p [13:33] I know it's a typo but I cannot find where [13:36] Yannig: but it worked like 1h ago? [13:36] Yep, but I updated the xip files :p [13:36] good thing would be to start what you changed afterwards [13:36] Yannig: entities are or of the form &entityname; [13:37] so if you typed anything with & or ; thats a good thing to start looking at [13:37] Yep, I think that's the only thing to do if there is no way to find where the error is [13:39] could be everything .... my guess is that its mainWindow.title that is borked [13:39] grep for that in your .po [13:39] or mainWindow.titlemodifiermenuseparator [13:40] Yannig: look into those two first .... otherwise try to remember what you translated [13:40] and look at those [13:40] ok off for an hour or so [13:40] food + coffee [13:41] Thanks :) === asac_ is now known as asac === fta_ is now known as fta [14:32] asac, i assume we don't want that: http://merges.ubuntu.com/x/xulrunner/REPORT [14:42] fta: yeah [14:44] we still have several packages depending on xul1.8, what did debian do for those ? [14:45] videolink, python-xpcom, kazehakase, hunspell, galeon, eclipse, zekr... [14:45] fta: they are migrating them now [14:45] i think just videolink will die [14:45] unless upstream comes up with something better [14:46] eclipse is xul 1.9 ready upstream ... so its probably just updating it [14:47] fta: python-xpcom is a xulrunner binary package [14:47] fta: so not relevant [14:51] i am sure there was a master/tracker bug for 1.8/1.9 transition. asked glandium now as i cannot find it [14:51] lets see when he replies [14:52] fta: here it is ;) http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=xulrunner-transition;users=glandium@debian.org [14:52] i've created a dquilt script. I can't stand the new behavior [14:56] hi all [15:00] hi defcon [15:00] hi asac [15:04] i have a problem with firefox3 as the case may be epiphany (ubuntu 64bit), when i type e.g. xampp into the google searchbar and click on the first link to xampp, the xampp page seems to be "behind" the google page. moving the mouse brings some parts from the xampp-page to the front. Same problem with epiphany. [15:04] is this a firefox problem? [15:05] or a bad coded webpage :D [15:06] defcon: you mean location bar, not search bar? [15:06] oetherwise i dont see how you can click on something and still keep the google result page [15:07] asac, the bar under the google logo [15:08] i made e screenshot from this 'feature' [15:12] asac, you wanna see it? [15:17] asac, http://www.sofaraway.org/ubuntu/tmp/bad-rendering.png [15:18] fta: cairo? [15:18] defcon: yes, please upload a screen [15:18] ok [15:18] asac, it's the text, "," and ")" are misplaced [15:20] fta: is "subscribed" a link? [15:20] yep, everything in blue [15:21] fta: actually, i see it too :) [15:21] never noticed with my eagle-eyes :) [15:21] asac: Can I bother you once more? :p [15:21] asac, http://xs128.xs.to/xs128/08240/bild1701.png [15:22] defcon: so the "start news team" thing doesnt belong there? [15:23] where does that come from? isnt that a separate application overlaying the webbrowser? [15:23] Do you see anything wrong in "./runpo2xpi xulrunner en-US.xpi xulrunner/oc.po"? [15:23] not sure [15:23] whay? [15:25] asac, the "start news team" belongs to the xampp page [15:25] defcon: might sound dumb, but tell me what is wrong with that screenshot :) [15:26] defcon: ah ok [15:26] defcon: whats the url? [15:26] from xampp? [15:26] yes [15:26] well i can read it ;) [15:26] wait a second [15:26] http://www.apachefriends.org/de/xampp.html [15:26] thx [15:26] np [15:27] defcon: grep EXA /var/log/Xorg.0.log [15:27] run that in a terminal. is there a match? [15:27] no [15:28] and: grep XAA /var/log/Xorg.0.log [15:28] ? [15:28] no [15:28] nothing [15:28] so how do you reproduce this: [15:28] 1. search xampp [15:28] 2. click on the link? [15:28] yes [15:28] defcon: first, try to disable your extensions in tools -> addons menu [15:29] asac: If your "whay" was for me => the result of that command makes me an xpi file recognized as "Firefox (oc)", instead of "xulrunner (oc)" [15:29] and that may be the reason why it bugged [15:29] Yannig: thats when you use the wrong en-US.xpi [15:29] you need to use the xulrunner one [15:29] Aaaaaaaaaaaaah [15:29] asac, addons are disabled and the problem still exists [15:29] there are two in the ubuntu langpack tarball [15:30] Dumb I am! [15:30] defcon: what graphics card/driver? [15:30] nvidia [15:30] defcon: using the proprietary driver? [15:30] e.g. nvidia ` [15:30] ? [15:31] nvidia-glx-new from the ubuntu repo [15:31] defcon: can you try the nv driver? [15:31] e.g. the free one? [15:31] yes of course [15:32] maybe give it a try. i had some wierd reports that got fixed by free nv driver in the past weekes [15:33] brb, installing nvidia [15:35] asac, i've committed dquilt to my mozilla-devtools branch, in case you're interested. [15:36] dquilt? is that the new thing for the new debian source format? [15:36] fta: ? [15:36] http://bazaar.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devtools/annotate/fta%40sofaraway.org-20080615135418-d9be9hfkp06lladq?file_id=dquilt-20080615135405-skcdgzx63rk3i5o8-1 [15:36] damn long url [15:37] ah :) ... now i remember [15:58] re [15:58] damn, after installing nvidia from nvidia page i got a problem with low resolution [16:00] asac, the problem still exists.. and nvidia is disabled [16:02] ah... now i installed firefox2 und the problem is gone! [16:03] looks like the infamous cairo xrender bug [16:10] brb [16:21] wb fta [16:22] err. one hour later ... still no progress [16:23] or was it even two hours? [16:26] ? [16:30] #debian-devel chatter about branch maintenance in debian and how to not cause pain on my behalf [16:36] brb [16:37] asac, on *your* behalf ? eh? [16:57] fta: yes, i frequently end up touching that package in security updates [16:58] which package ? [16:58] xul [17:15] asac, you wanted to discuss with me about something yesterday [17:33] fta: yeah. the extension upstream branch syncher [17:33] i think we should just get things started [17:33] what i would like is to have ascript: [17:34] sync-upstream-branches lp:~mozillateam/firefox-extensions/upstream-branch-config [17:34] so all information required for that otherwise configless script would be in the upstream-branch-config [17:35] somewhat that script should reuse the current upstream branches i guess [17:36] but that shouldnt be difficult i guess and would involve moving the current upstreawm branch to the expected location [17:40] ok [17:40] makes sense [17:41] fta: how about these properties for each upstream branch: [17:42] packagename, AMO ID, branchname [17:42] or maybe even without packagename ;) [17:42] and in the config file have the following global properties: [17:42] sometimes, there's no AMO ID [17:42] fta: ok [17:43] TYPE, branchname, typedata [17:43] TYPE=AMO,... [17:43] ? [17:43] packagename could be upstream name, or ubuntu all-lowercase name [17:43] not sure if we want to throw all configuration in the same file [17:43] sync-upstream-branches doesnt require packagename [17:43] for now [17:44] one file per project like mozclient [17:44] ok [17:44] so xml? [17:44] or just [17:44] TYPE=AMO [17:44] AMOID=3111 [17:44] upstreambranch=xxxx [17:44] i would also like global properties in a global file: [17:45] key=value syntax is enough IMHO [17:45] LP-UPSTREAM-LOCATION=lp:~mozillatewam/firefox-extensions-upstreawm [17:46] so we could have upstream-branch-config/projects/firegpg.conf [17:46] and upstream-branch-config/global.conf [17:48] we need a way to specify which additional mozilla tools each ext supports, in case upstream doesn't care about let's say sm, or flock but we know it's ok (tested) [17:49] for that, we need a global list of IDs with associated max versions [17:50] ...list of mozilla tool IDs [17:50] not ext ids [17:52] yes, but that is package branch related. not upstream [17:53] for now thats done when bootstrapping the package imo ... you take care that you have the proper directories in debian/rules [17:53] or are you saying you want to patch those? [17:53] fta: you can also patch flock in the packaging branch. the merges should cope with that quite well i guess [17:56] depends if you want a patch system inside each app. or just a global browser ID map overriding the choice made by upstream [17:57] choices [17:57] for extensions we dont want a patch system [17:58] the workflow for adding changes should be as simple as editing upstreawm sources and committing [17:58] oh shit ... have to catch my train ... bbl [17:58] ok, see you. i'll think about this [22:33] fta: still awake? [22:33] yes [22:33] sorry, but when i arrived i was supposed to look soccer i was told ;) [22:33] :) [22:33] fta: was a funny game ;) [22:34] the turks goal keeper got red car in the last few minutes ;) [22:34] red card [22:34] hehe [22:36] fta: so where were we? [22:38] no patch system but in source changes in the .ubuntu branch [22:38] ah right [22:38] i am currently branching mozilla-devtools [22:39] i've started some code in there [22:39] yeah [22:39] but nothing committable so far [22:39] check-extensions.sh [22:39] no, classes for extensions [22:40] you mean "upstream-type-classes" ? [22:40] e.g. AMO, svn, etc.? [22:41] so far, the main class to parse ext conf files [22:41] i have to think about which fields are needed [22:41] ok. for now try to keep things as stupid as possible [22:41] e.g. just synching upstream for now [22:42] amo-id = \d+ (or 0 or even no key at all in case it's not maintained on AMO) [22:44] is the upstream vcs url needed ? it's already known by LP, so the LP .upstream branch should be enough [22:44] depends how this is designed. if you have have a field for "type" and some type doesnt have AMO id then we dont need a 0 or empty field at all for that [22:44] fta: how is it known by launchpad? [22:44] we don't want to auto-sync that ? [22:44] fta: svn? [22:44] oh, my bad, it's not always possible [22:45] imo we should care for AMO only atm [22:45] the rest is not really understood imo [22:46] e.g. what is an upsream branch. how to figure release tags, what about branches, and so on [22:46] (damn, my pc is slow.. i've been trying to install a qemu guest for 4h+, 100% cpu since the beginning, and now it's stuck at 94% in grub) [22:47] at least for upstream auto-sync we should ignore svn. [22:47] later when we come to merge automization we might support auto merging upstream branches that are synched in a different way [22:47] e.g. AMO => auto synched; rest => sync upstream manually or through launchpad. [22:48] until its really understood how to track upstreams from their VCS [22:48] we should draft that, wiki or something, so ideas are not lost [22:48] yeah. [22:49] should I start a new page ? [22:50] fta: the large scale maintenance page is probably the right place [22:50] there is a section about the components [22:50] for the auto-syncher it alreay reads " * [22:50] auto import new upstream releases. This document suggests to first implement the auto sync for AMO .xpis and later define how VCS imports could be implemented effectively. [22:50] " [22:50] we should refine what is under Component section imo from our discussion [22:51] fta: https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/LargeScaleMaintenance .... take a look and lets discuss changes based on that [22:51] I'd fork the auto updater in a auto syncher and auto merger [22:53] ok, but before that, we need a framework.. per ext conf files, and a global conf file. what should they contain respectively ? [22:53] this framework will be turned into a class used by all the scripts [22:55] fta: ok. I agree that we should define how configuration files syntax are [22:56] and how configurations are loaded: "e.g. 1st. global conf and 2nd. ext conf files that can probably overload values set by global conf files [22:56] key = value [22:56] # comment [22:57] fta: yes. i am fine with simple key = value format. but please no perl language elements in the value ;) [22:57] that's the basic syntax, now we should list the keys [22:57] fta: we already discussed the keys i think [22:58] no perl in the conf file. if something must be evaluate, it should be through system() or shell.. in fact, like mozclient [22:58] yes, but please lets consider evaluation of conf values a last resort measure [22:58] i would like to keep that option out of the .conf file spec as long as possible ,) [22:59] getting the ext version is not always straight forward. look at adblock-plus [22:59] fta: i think we should only care for kesy required for synching now [22:59] fta: well ... for AMO its always straight forward [23:00] for other we might allow to hook-in helper scripts ... but we can look at that when we are there [23:00] k [23:01] so lets assum we have AMO, its just the AMO-ID + the branchname that is required for synching [23:01] if the branchname is not a full URL we can put a dir.bzr.upstream variable in the global config [23:02] do we need more info for AMO itself? [23:02] hm, i don't think so [23:02] on top we only need a ext.upstream.type = AMO (later svn or whatever) variable to allow addition of new methods afterwards [23:03] fta: should we introduce kind of syntax to express which class level which confguration property belongs to? [23:04] e.g. general.branchname = mysuperbranch [23:04] e.g general.upstream.method = amo [23:04] e.g. amo.id = 12912 [23:04] in fact thats why i like XML better ;) [23:04] we could define schemas and have derived types ;) [23:05] but well ... for this quite simple task key value should be good enough [23:05] i like xml very much but so far, i see 2 fields, no need for hierarchy or xml [23:05] hehe [23:06] even general.upstream.method = amo could be seen as key = value, doesn't matter much to me that key contains "." [23:06] fta: i didnt say different [23:06] that was my suggestion for key/value [23:07] but lets look at the names again. how about prefixing keys with the script they apply to? [23:07] sync.method = amo [23:07] not sure [23:07] maybe just [23:07] branchname [23:07] method [23:07] amoid [23:08] lp-repo [23:08] i'd like a packagename key or something like that. translating the ext name is into a package name is not always direct [23:08] fta: for upstream sync we dont need a packagename [23:08] that will come at merge stage [23:09] packagename could replace all the branch names, if we follow the branch naming conventions described in the wiki [23:09] * asac thinking [23:09] sound right ;) [23:10] amo-id = 1865 [23:10] package-name = adblock-plus [23:10] but take that with a grain of salt. imo the syncher shouldnt really know semantically anything about the packaging concept [23:10] maybe packagename == branchname always [23:10] so i dont mind ;) [23:14] ok the wiki says that we are using only one autoupdater config branch [23:14] so lets use autoupdate.config/global.conf + autoupdater.config/upstream/xyz.conf [23:14] and merge configs should go into autoupdater.config/packages/xyz.confg [23:15] hmm [23:15] and merge configs should go into autoupdater.config/packages/DISTRO/xyz.conf [23:15] maybe? [23:15] e.g. DISTRO = hardy or hardy-backports and so on [23:15] hardy-proposed could point to a different upstream branch than hardy-backports [23:16] do we need a DISTRO level for upstream too? [23:16] or do we have different autoupdater.config.hardy, autoupdater.config.hardy-prpopsed [23:16]