[01:03] can anyone tell me, when installing flash10, should I install to /usr/lib/firefox or /usr/lib/firefox-3.0 ? [09:13] hi [09:14] sorry, was gone for the sweeked [11:29] asac: hey there [11:29] jtv: yeah. great to see you [11:29] was just about to hunt you ;) [11:30] asac: uh-oh... is this where I'm given 10 seconds to run or hide? [11:30] jtv: too late ;) [11:30] jtv: but first, what can i do for you? [11:30] asac: actually, it's sort of more a thing I've been doing for you, that you could test. [11:30] asac: I prototyped xpi export this weekend. [11:31] jtv: \o/ [11:31] sounds cool [11:31] asac: sudden inspiration [11:31] asac: even does multiple languages in one file. [11:31] so you did a complete rewrite? [11:31] asac: I know of several things that are still missing though: [11:32] No no no, it was just a matter of writing a new export plugin. Not an easy one, mind you, but the existing code is intact. [11:33] asac: still missing: install.rdf generation, merging in the non-locale files from the template, those special tags that don't carry any translations, and some details on template export. [11:33] jtv: ok [11:33] sounds good [11:33] asac: I'm not sure which of those you need, and some of them could be very hard. [11:33] jtv: we have the install.rdf generation code in the po2xpi thing [11:33] asac: gimmegimme! [11:34] jtv: err. its a filter actually based on the en-US.xpi install.rdf [11:34] asac: that's pretty much what I need (though we can add some of our own metadata as well) [11:34] just: cat en-US.xpi/install.rdf | sed -e 's/en-US/YOURLOCALE' [11:35] well with proper syntax [11:35] asac: duh [11:35] jtv: the other nifty thing you have to do is setting up proper defaults [11:35] for cases where we have two country codes for one language [11:35] * jtv shivers [11:36] jtv: you have two chrome.manifest i guess right? [11:36] well ... most likely concat'ed into one for the final en-US.xpi [11:36] asac: two? [11:36] one for pt-PT and one for pt-BR [11:36] One XPI file, one chrome.manifest. I know it's harsh, but they don't grow on trees you know [11:37] I've produced a very simple canonicalized layout, so a manifest may look like: [11:38] locale de foo jar:locale/de.jar!/foo/ [11:38] locale fr foo jar:locale/fr.jar!/foo/ [11:38] locale de bar jar:locale/de.jar/bar/ [11:38] etc. [11:38] (actually, sorted by locale) [11:39] jtv: and for pt? [11:39] asac: it depends on what's in your database. If you wanted, you could have pt, pt_PT and pt_BR and you could export them all in a single xpi file. Each of the 3 would have its own jar file and its own manifest entriese. [11:40] *entries [11:40] * jtv makes a note that the manifest wants to use dashes, not underscores, to attach country codes to language codes [11:40] jtv: ok. let me tell what we are currently doing for pt-PT [11:41] and pt-BR [11:41] we have entries for both and add entries for "pt" which point to the locale we want to be default for LANG=pt [11:41] or LANG=pt_UNKNOWN [11:41] understood? [11:42] so we have locale pt-BR jar:...pt-BR.jar!/... [11:42] and locale pt-PT jar:...pt-PT.jar!/... [11:42] asac: ah, an example helps, thanks. [11:42] and locale pt jar:...pt-PT.jar!/... [11:42] asac: for import we don't support multiple languages in one file yet, so what happens is this: [11:42] you upload a file. If it's e.g. pt.xpi, that's easy; it gets auto-approved. [11:43] jtv: no its for export [11:43] jtv: we need at least the same features we have now ... where we upload pt-PT.xpi and pt-BR.xpi ... and export that all into the same pt.xpi ;) [11:44] asac: shouldn't be a problem. You just browse to the *template* and request a download of pt and pt_BR, in XPI format. [11:44] That'll give you a single xpi containing both languages. [11:44] asac: there is one catch, of course. [11:46] jtv: ok, so where can i test current code? [11:46] Since we stick to the convention of "pt" rather than pt_PT, the two languages in your export (right now) will be pt and pt_BR [11:46] k [11:46] asac: if you've got devpad access, you can bzr my branch from there. [11:48] jtv: i doubt i have that ;) ... so what do you want me to test? or did you just want to talk about this? [11:50] asac: ah, you didn't think all this came for free, did you? :) [11:50] asac: I want to produce some test files for you, and ask you to see if they're any good. [11:55] jtv: ok cool [11:55] jtv: my question was more of bug nature ;) [11:55] asac: go ahead [11:56] jtv: did you came to fix the comment (//) issue in .properties files? [11:57] asac: yes and no [11:57] asac: I still need to write the tests. [11:58] ok [11:58] bumb [11:58] jtv: https://translations.edge.launchpad.net/ubuntu/hardy/+source/xulrunner-1.9/+imports [11:58] there are two items that need review? [11:58] asac: bumb! [11:58] armin76: what? [12:01] asac: bumb yourself! [12:04] asac: did we really want that old fi.xpi blocked? I thought it was a mistake, in which case we'd better just delete it. [12:04] jtv: i cant remember what that upload was about [12:05] jtv: afaik all except the // thing is ok now in fi so we probably dont want that [12:05] jtv: en-US.xpi needs to be approved though [12:05] asac: ahhh, wasn't that the one with some problem that made the import fail? [12:05] didi i forget to tr - _ ? [12:05] asac: I already approved those two. [12:05] asac: not in the filename, that's for sure! [12:13] jtv: ok ... also uploaded en-US.xpi for ffox 3 [12:13] thanks! [12:13] (for approval) [12:14] https://translations.edge.launchpad.net/ubuntu/hardy/+source/firefox-3.0/+imports [12:15] asac: that should be auto-approved, no? [12:16] jtv: hmm. not sure [12:16] why would that be auto approved, but the previous xulrunner one not? [12:17] asac: auto-approval may take a while. [12:59] hi Jazzva [12:59] hey asac :) [12:59] Jazzva: how are you? [13:00] asac, good :). Had an exam on Saturday at 8am, still feeling tired. You? [13:00] not so bad either ;) [13:01] Jazzva: how was your exam? [13:01] went well? [13:01] asac, this one did went well :)... telecom exam didn't. but, that's ok for now [13:01] Jazzva: you think you have to redo telecom? [13:02] I know. I failed it (as most of the people who did it) [13:02] hmm. sry for that [13:02] exams are one of the things i certainly dont like to do twice ;) [13:04] no problem :). I had to do some of them more than once... [13:04] asac: btw, do you know where I can find wiki administrators? [13:06] asac, and is it ok if I move MT/Firefox3Extensions/LargeScaleMaintenance to MT/Extensions/LargeScaleMaintenance? [13:08] Jazzva: not sure about wiki admins. feel free to rename the LargeScaleMaintenance page ... can you figure if we can create a redirect or somethign? [13:09] asac: I think it automatically creates a redirect when a page is renamed. But I didn't know that when I started, so I created new pages. Then I found that out, so I deleted the new pages, and tried to rename the old ones. Now it reports I can't rename them, since those pages already exist. Let me try again. [13:12] heh, not redirecting for LargeScale... Let me check help for moin wiki [13:34] asac, we can redirect [13:34] just add "#REDIRECT NewPage" in the OldPage. [13:35] https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/LargeScaleMaintenance [13:42] Jazzva: cool [13:42] I'm doing that for the rest of the extensions' pages now [13:43] Jazzva: largescale does not yet redirect form e [13:43] for me [13:44] it doesn't? Weird. It always redirect and shows notice at the top of the page [13:44] try to refresh page :) [13:44] maybe it didn't pick the new one, and loads it from cache [13:45] Jazzva: ah ok [13:46] thanks [13:46] np [13:46] hmm ... still doesnt redirect [13:46] just shows that it wants to [13:46] but that never happens [13:46] try with http://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/Packaging [13:47] btw, do we need this one: https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/Bzr ? Most of those instructions are incorporated in Packaging page [13:49] i think it works now.. wierd [13:50] Jazzva: the packaging page is ment to be a tutorial page ... that doesnt cover all cases [13:50] so yes, Bzr page makes sense. just needs to be populated with more use-cases [13:50] (imho) [13:51] Ok... I'll see with gnomefreak what did he planned to do with it :) [13:52] and I think we can ditch this one: https://wiki.ubuntu.com/MozillaTeam/Firefox3ExtensionsReview , when we move some of the contents to MT/Extensions/List [13:54] Jazzva: yeah ... delete the review page [13:54] asac, you also created this one: https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/BogusList ... We keep that info in tables at List page, so I'll remove BogusList [13:55] if you add the ones that are not on Extension list to the table that "is missing info" that would be great [13:55] but not needed imo [13:55] I planned on doing that [13:56] Jazzva: i am not sure if the normal list page shouls also get the bogus list [13:56] that table was ment to track reported issues [13:56] e.g. if someone files a bug like "this freature is broken" and finall we find that its caused by extension X [13:56] we keep "Extensions that are not suitable for Ubuntu" table at the list page [13:56] we would add that incident to that page [13:56] aham... ok [13:56] of course so far we didnt do that ;) [13:56] so not sure if thats the right thing [13:56] so, it's not the same as "not suitable extension" list [13:57] just to know :) [13:57] maybe tagging bugs that someone confirmed as being "extension caused" [13:57] would be a good start [13:57] Jazzva: yeah. its different [14:04] jtv: so now all is imported. do we have to wait for a new delta tarball to arrive based on this? [14:05] or can we trigger the creation of a delta now? [14:20] jtv: if you used the po2xpi code we had, then you could have used runpo2xpi to do the copying of the non .dtd/.properties files as well as the install.rdf creation [14:24] asac: how do you map the directory layouts between the "template" (en-US) and the translation? [14:25] asac: about the deltas: those are for the entire Ubuntu release, so better coordinate with Arne & Martin. [14:34] jtv: the directory layout is always the same [14:34] with en-US replaced by xx-YY [14:34] in the end those files should be single translatable entities imo [14:35] e.g. one entity for the complete file [14:35] which then the po2xpi transformer identifies and handles correctly [14:38] asac: translatable? So that means that you don't always want the versions from the en-US.xpi? [14:43] asac: think I lost my connection for a bit there. [14:54] asac: sorry, connection trouble. I know how to fix it, but believe it or not, getting it fixed involves contacting my favourite pizza place. === jt1 is now known as jtv [14:59] jtv: haha [14:59] jtv: well. if they are in en-US.xpi and they are resolvable through a chrome://xxx/locale/ URI, then those are in the end translatable files [14:59] like complete .xhtml files [14:59] or images. [14:59] i think we dont want to support images right from the beginning [14:59] but xhtml file translation would be great [15:01] asac: probably not this week though :-) [15:02] asac: I was thinking it might be healthier for now to produce a simple canonical directory structure, and if people want to merge other files into the XPI, they can just unzip/add/rezip. [15:03] asac: though I do understand that you'll probably want complete, merged xpi archives. [15:03] asac: one big advantage of what I have right now is that it works without looking at the en-US.xpi at all. [15:04] asac: and it keeps a very simple mapping between chrome paths and "xpi paths." [15:04] asac_: ah, having trouble as well? [15:04] no ... i think this was daily reconnect ;) [15:05] emphasize on "think" ;) [15:10] asac_: the files from en-US.xpi that you'd want merged into a translation... do they all live in the locale directories covered by the locale entries in the manifest? [15:12] jtv: if they are not accessible through a locale/ directory, then we dont need to copy them [15:18] asac_: I see. That was the one big question I had. At some point I'll have to scan the en-US.xpi as part of the export process anyway, so that's doable without adding too much weight. [15:19] asac_: what I've done for now has the advantage of not needing any knowledge of the template, and keeping a simple mapping between chrome paths and directory layout. === asac_ is now known as asac === Moot2 is now known as MootBot [17:51] hi [17:53] asac: I saw the Flashblock bug [17:54] does something need to be done to backport it to hardy ? [17:54] I proposed to merge a branch a couple of week ago I think [18:24] rzr: you want to backport a bug? [18:24] i'd suggest to backport the fix ;) [18:24] hehe [18:24] rzr: we havent yet setup the auto-notification if you suggest a merge [18:24] it = flashblock :) [18:25] auto-notification ? did I miss something ? [18:26] rzr: no ... thats nothing you missed, but we missed it [18:29] rzr: we cannot upload a "may fix something unknown" to -proposed [18:30] we should upload this to hardy-backports [18:30] and once we know about a specific bug get a minimal patch to -proposed [18:30] ok [18:30] rzr: just change the changelog target to hardy-proposed [18:30] and document that its a upload to backport [18:31] * backport, may fix trouble with firefox 3 [18:31] if you have "may", just leave that part [18:32] rzr: just change the changelog target to hardy-proposed [18:32] or hardy-backoprts ? [18:32] -op+po [18:35] rzr: backports [18:36] rzr: did i upload the release to intrepid yet? [18:36] ok this makes sense now [18:36] yes you did [18:36] ok [18:36] you asked me this twice :) [18:36] rzr: use the same bug id in changelog [18:36] rzr: today? [18:36] last week :) [18:36] ok, then i am not scared about brain-damage ;) [18:38] rzr: can you also change the Vcs-Bzr header to point to the backports branch? [18:38] Vcs-Bzr: https://code.launchpad.net/~ubuntu-dev/firefox-extensions/flashblock.ubuntu.hardy-backports [18:38] let's do this now .. [18:39] rzr: wait a second ;) ... let me think if thats the right procedure (in regards to auto merging) [18:42] about the version name [18:42] rzr: i think should be fine [18:42] no. all fine [18:42] just do as said [18:42] see : https://launchpad.net/ubuntu/+source/cmake [18:42] change Vcs-Bzr header like above [18:43] 2.6.0-4~hardy1 [18:43] while [18:43] you suggested me to name it : 1.3.10a~snapshot20080611-0ubuntu0.8.04+backports.1 [18:43] rzr: no [18:43] this is not about version [18:43] this is about branch name [18:43] the version is ok like this [18:43] ok I see [18:44] just hardy-backports for the distribution [18:44] humm [18:44] i am not sure we talk about the same thing [18:45] the cmake guys just added ~hardyN to package version which was in X-Y form [18:46] you explained me that wont fit because it's not in X-(Y minus 1) form [18:49] well I commit this changeset then [18:52] asac: at your service sir : http://bazaar.launchpad.net/~rzr/firefox-extensions/flashblock.ubuntu/revision/12 === rzr is now known as rZr [19:11] asac: hows that you don't use the distro useragent string on ff3? [19:56] hello [21:10] stek79_: hi [21:13] asac, we did previous package for foxyproxy from xpi file. But there is a svn repo, which provides the build script and the rest. Should we switch to that one? [21:14] the build script is not present in the xpi file [21:31] Jazzva: its not yet really understood how the auto syncher/merger would work for svn upstreams [21:31] so for now we might wanna stick with svn [21:31] err, xpi ;) [21:32] easier for me :) [21:33] Jazzva: how do we unpack .xpi's? [21:33] do we we have a standard format? [21:33] i use unzip :) [21:34] Jazzva: yes, but the chrome jars need to be unpacked too [21:34] just committing .jar files is ugly [21:34] download xpi, unpack it, unpack chrome.jar (if present), create rules that will zip it all up, install, and then remove jar on clean [21:34] it's two more lines of code [21:34] Jazzva: where do you unpacke chrome.jar? [21:34] to chrome/ [21:34] Jazzva: what do you do when there is more than one .jar in crhome? [21:34] this extension have icons/ and foxyproxy.jar in chrome/. [21:34] should be quite common [21:35] More than one? Still haven't bumped into that [21:35] really [21:35] hmm [21:35] we should do something about that imo [21:35] But I suppose I would use debian/some_temp_dir [21:35] Jazzva: yes, but we need a working standard [21:35] so every xpi extension is done in the same way ;) [21:37] COUNT = 0; for JAR_FILE in `find chrome -name *.jar` ; do unpack_to($TEMP_DIR+$COUNT) ; $COUNT++ ; done [21:37] in pseudo-bash-pseudo-code :) [21:37] well. you would loose information about the name [21:37] $JAR_NAME+$COUNT [21:37] :) [21:37] upack_to "$JAR_FILE!" [21:38] why count? [21:38] oh, right :) [21:38] $JAR_FILE should be unique [21:38] yep, agree.. [21:38] append the ! which is used in chrome.manifest to denote a .jar delimiter [21:39] Jazzva: ok, then we need a script to xpi_unpack [21:39] and xpi_pack [21:39] ok, i'll try to make it. where to put it? [21:39] :) [21:39] Jazzva: mozilla-devscripts [21:39] inside xpi.mk? [21:40] Jazzva: depends. i think we should make scripts out of them and then add convenience rules to xpi.mk that basically use xpi_pack [21:40] Jazzva: the scripts should be installed in $bindir [21:40] e.g. /usr/bin/ [21:40] ltes name them mds-xpi-unpack and mds-xpi-pack [21:41] or [21:41] med-xpi-... [21:41] k [21:41] whatever you prefer [21:42] off to dinner now. I'll see what I can do tonight :) [22:23] asac, which mozilla-devscripts branch to use :)? [22:32] <[reed]> asac / fta2: where do you all disable safebrowsing? [22:32] <[reed]> I couldn't find it [22:51] [reed]: its not disabled (anymore) [22:51] Jazzva: which branches do exist? [22:51] Jazzva: https://code.edge.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts [23:04] asac, sorry, was away from keyboard. Thanks for the link [23:27] do i need to be scared of my email tonight?