[01:21] <Ubulette> a8 mt3 succeeded
[01:22] <Ubulette> got no mail though
[01:23] <asac> successful builds are usually not mailed
[01:24] <Ubulette> oh, ok
[01:51] <bluekuja> heya asac
[01:51] <bluekuja> :)
[02:33] <asac> bluekuja: hi ... all fine?
[03:12] <Chiselhuk> Hi Can anyone here help me plse??
[03:13] <Chiselhuk> Having trouble with Mozilla Firefox crashing continually in Ubuntu Gutsy Gibbon!
[03:14] <bluekuja> asac: yup :)
[03:14] <bluekuja> asac: I'm studying atm, and later I'll move to fix two agg's bugs
[03:15] <bluekuja> asac: I hope to have them fixed as soon as I can, NM waits me
[04:01] <asac> hehe
[04:59] <carlos> asac: please, ping me when you are back
[05:04] <asac> carlos: ping
[05:04] <carlos> asac: hi
[05:04] <asac> ok how can we get this going
[05:05] <carlos> asac: so, I'm starting implementing the export code to get translations from Launchpad and generate language packs for packages using Mozilla XPI file format
[05:05] <carlos> I did some investigation after our last chat
[05:05] <asac> yes
[05:05] <carlos> and indeed, using .manifest files is the way to go
[05:06] <asac> so how does it currently work?
[05:06] <asac> do you get initial strings from upstream xpis?
[05:06] <carlos> I talked with pitti about how to extract those files on build time like we do for other translation formats and import automatically into Launchpad
[05:06] <carlos> the idea is, you upload a new package into Ubuntu's archive
[05:06] <asac> new package == new firefox package ?
[05:06] <carlos> we extract the strings automatically and import them into Launchpad
[05:07] <asac> ok
[05:07] <carlos> asac: new firefox or any other package that uses xpi files
[05:07] <carlos> the problem is that not all packages are using XPI files
[05:07] <asac> right
[05:08] <carlos> and Martin thought is not a good idea to look for .manifest files + all the subdirectories inside that directory
[05:08] <carlos> because is move file format dependent information in a layer that shouldn't know about it
[05:08] <carlos> so he asked me to check with you whether we could use xpi files inside source packages
[05:08] <carlos> instead of having it uncompressed (like ubufox does)
[05:09] <asac> ubufox currently has no translations
[05:09] <carlos> then, the package build will extract the xpi file content and do the usual things
[05:09] <asac> its actually the same way firefox ships its en-us locale
[05:09] <carlos> yeah, that would need to be updated too
[05:09] <carlos> if possible
[05:10] <carlos> so we only need to look for .xpi files
[05:10] <carlos> and move the logic inside Launchpad and the packages that use it
[05:10] <asac> hmm
[05:10] <carlos> the .xpi file doesn't need to be locale specific
[05:11] <carlos> we are able to discard the bits that are not related with translations inside Launchpad
[05:13] <asac> hmm why do we start with source files at all?
[05:13] <asac> why not look at the contents of the binaries?
[05:13] <carlos> because it's at that level where we get the information for Launchpad
[05:13] <carlos> the extraction process is triggered on build time
[05:14] <carlos> by the pkgstriptranslations script
[05:14] <asac> thats hooked into some standard debhelper command?
[05:14] <carlos> yes
[05:14] <asac> or how is that triggered?
[05:14] <asac> which one?
[05:14] <carlos> I don't know so much details
[05:15] <carlos> let me see whether pitti would join us
[05:15] <asac> yes
[05:15] <carlos> he's the one handling that part
[05:15] <asac> thats probably a good idea
[05:15] <pitti> hello
[05:15] <asac> ola pitti
[05:16] <asac> 17:13 < asac> hmm why do we start with source files at all?
[05:16] <asac> 17:13 < asac> why not look at the contents of the binaries?
[05:16] <asac> 17:13 < carlos> because it's at that level where we get the information for Launchpad
[05:16] <asac> 17:13 < carlos> the extraction process is triggered on build time
[05:16] <asac> 17:14 < carlos> by the pkgstriptranslations script
[05:16] <asac> 17:14 < asac> thats hooked into some standard debhelper command?
[05:16] <asac> 17:14 < carlos> yes
[05:16] <asac> 17:14 < asac> or how is that triggered?
[05:16] <asac> 17:14 < asac> which one?
[05:16] <asac> 17:14 < carlos> I don't know so much details
[05:16] <pitti> asac: dpkg-deb
[05:17] <pitti> asac: that kills *.mo from debs and also extracts po files, etc. from the source tree into a trasnaltion tarball for Rosetta
[05:17] <pitti> plus some custom stuff for OO.o and Mozilla (extract .xpi, etc.)
[05:17] <asac> pitti: can we take a look at the binary results at that point?
[05:17] <pitti> so, just to set the topic, the goal is to extract the rigth set of files for Rosetta from the builds of firefox itself (en-US) and ubufox, right?
[05:18] <carlos> pitti: yes
[05:18] <pitti> asac: we need to mangle at build time, and use the source; we need to strip off .mo files, and the binaries do not have *.po which we need for Rosetta
[05:18] <carlos> asac: what's the point on doing it for binaries instead of source packages?
[05:18] <asac> point is that almost no mozilla source tree has .xpi files ... and that is impossible to change
[05:19] <asac> impossible == without changing the world ;)
[05:19] <carlos> asac: well, that's done *after* source build
[05:19] <pitti> ok
[05:19] <carlos> so it could be done after you build the xpi file in hte source build
[05:19] <pitti> so, which files do we actually need?
[05:19] <carlos> asac: we take that same approach to update all .pot files before extracting them
[05:20] <pitti> we need to balance simplicity of pkgbinarymangler with special knowledge about mozilla-like translations
[05:20] <asac> pitti: we have to search the binary tree for .jar files and extract the entities from there
[05:20] <pitti> asac: that's something the Rosetta importer should do
[05:20] <carlos> asac: no, that's not done at that level
[05:20] <pitti> at build time, the most complex operation possible is "find some files and copy them into the tarball"
[05:20] <pitti> if that grabs a few files too much, it doesn't hurt
[05:21] <pitti> it shouldn't be too many to avoid getting too big tarballs, of course
[05:21] <carlos> asac: then, Launchpad gets that tarball and process it to extract the translations
[05:21] <carlos> but that happens after the build and publishing process ends so we don't interfere with buildd
[05:23] <asac> ok please look at: http://paste.ubuntu.com/603/
[05:23] <carlos> from my position, what would be quite useful is to add a rule to the packages that use Mozilla l10n infrastructure to generate the .xpi files we need
[05:23] <carlos> and execute that rule before the pkgstriptranslations
[05:23] <asac> usually you would have to take all .jar files that have a locale reference in their manifest
[05:24] <carlos> asac: that's why I talk about xpi, if you zip all those files inside an .xpi file, Launchpad will do that research
[05:24] <carlos> after the package is built
[05:24] <asac> thats not possible ... really
[05:24] <carlos> and pitti's script will only need to know what to extract, because it finds the .xpi file
[05:25] <carlos> hmm
[05:25] <pitti> how many source packages are we talking about? just firefox and ubufox?
[05:25] <asac> i don't understand why you can deal with .xpi while you can't with arbitrary chrome jars
[05:25] <asac> pitti: in the end about all mozilla related packages
[05:25] <pitti> for two packages it makes sense to keep the special logic in their debian/rules, since *.manifest files are by no way mozilla specific
[05:25] <asac> pitti: firefox and ubufox are good corner cases
[05:25] <asac> if both work, most others should work too
[05:25] <pitti> .jar files are mozilla specific
[05:26] <pitti> so if we just extract all .jar files, would that work?
[05:26] <carlos> pitti: no, I need the manifest file too
[05:26] <carlos> pitti: also ubufox doesn't use jar
[05:26] <pitti> meh
[05:26] <asac> pitti: the problem is that you have to generate a proper .manifest file during export ... look at /usr/share/firefox/chrome/en-US.manifest
[05:26] <carlos> it has the files uncompressed
[05:26] <pitti> . o O { gettext FTW! }
[05:26] <asac> the only way this can be done right is too parse all .manifest files
[05:26] <asac> and from there go on.
[05:26] <pitti> that's not something we should ever do for all packages in pkgbinarymangler
[05:27] <carlos> pitti: what about the approach I told you about?
[05:27] <carlos> extract all *.manifest files and any file in subdirectories where that file is
[05:27] <carlos> but
[05:27] <asac> there are different ways to reference locations inside that ... jar: is one option, but there might as well be just directories ... like you can see in ubufox chrome.manifest
[05:27] <carlos> restrict it to a well known list of packages
[05:28] <carlos> asac: I know about that, but we don't want to add that logic to the extract process
[05:28] <carlos> but leave it inside Launchpad
[05:28] <carlos> so we don't need to maintain different code in different places but just in a single place
[05:28] <pitti> so, what about:
[05:28] <asac> carlos: without looking at .manifest you won't be able to export them in a usable fashion.
[05:28] <pitti> if there are any .jar files, extract those, plus all *.manifest
[05:29] <pitti> that's simple enough for pkgbinarymangler
[05:29] <carlos> asac: I want that .manifest file so I will be able to generate the right export, don't worry but at Launchpad level
[05:29] <carlos> pitti: that leaves ubufox outside, it has .manifest files but it lacks .jar files
[05:30] <carlos> pitti: https://pastebin.canonical.com/461/
[05:31] <asac> carlos: can you psate to paste.ubuntu.com ?
[05:31] <asac> i don't know the pass ;)
[05:31] <pitti> seriously, we cannot code 10 special cases into pkgbinarymangler
[05:31] <pitti> special cases should be handled by the particular source packages
[05:31] <carlos> asac: it's just the content of the ubufox source package
[05:31] <asac> pitti: its not a special case ... its just: look at .manifest ... and use the method listed there
[05:32] <asac> in the forth column: if there is jar:... you can find the right .jar file and extract that ... if its just a directory, you would just use that
[05:32] <carlos> asac: it's even more simple, extract everything in the directory where .manifest is and we will handle the parsing later
[05:32] <carlos> pitti: ^^^
[05:32] <asac> carlos: maybe that would work
[05:33] <asac> but export needs to be smart then
[05:33] <carlos> if you have concerns for packages using different manifest files, let's lock that extraction to a well known list of sourcepackages
[05:33] <pitti> carlos: we need an additional condition when to do it
[05:33] <carlos> asac: we use the import to generate the export
[05:33] <pitti> *.manifest is way too generic
[05:33] <asac> i would prefer to teach the pkgbinarymangler how to deal with:
[05:33] <asac> locale necko en-US jar:en-US.jar!/locale/en-US/necko/
[05:33] <asac> and
[05:33] <asac> locale  ubufox  en-US   locale/en-US/
[05:33] <asac> that will cover all cases i guess
[05:34] <carlos> asac: really, that's useless at that stage
[05:34] <asac> carlos: why? you would get the right list on what you want to import into launchpad
[05:35] <carlos> asac: because that adds more complexity and we can handle the filtering on Launchpad side where we need to know about .manifest content anyway
[05:35] <asac> ok
[05:35] <carlos> pitti: combined with a well know list of sourcepackages shouldn't be a problem...
[05:35] <asac> but you could at least filter out not needed .jar files/directories
[05:36] <pitti> right, we need something dead simple and 100% robust in the binary mangler
[05:36] <carlos> asac: right, that would generate smaller tarballs, although it's not a big problem, we could even get the source tar.gz imported into Launchpad, we ignore the files that are not interesting for us
[05:37] <carlos> so if it adds extra complexity, let's not do that
[05:37] <carlos> asac: what's the list of sourcepackages that use Mozilla like translations? Do you know that list?
[05:38] <asac> ok ... to summarize: we use the binary results present at the end of build
[05:38] <carlos> asac: just to clarify, that's not the binary packages, but the final version of the built  package
[05:38] <asac> and unzip all .jar files that are in a directory that with at least one chrome.manifest?
[05:39] <carlos> asac: no need to unzip them
[05:39] <asac> i don't understand the difference ... for me its just debian/firefox or debian/ubufox at the end of build
[05:39] <asac> no need to unzip?
[05:39] <carlos> no, Launchpad will inspect them
[05:39] <carlos> based on the manifest files
[05:40] <asac> ok, so why wouldn't ubufox work at the moment?
[05:40] <asac> i understood that launchpad would choke on that if we don't do anything
[05:41] <carlos> if pitti agrees on extract directory and contents that have a  *.manifest file inside it for a given list of packages (so we only do that for packages that are really using this kind of translations)
[05:41] <carlos> ubufox will work without changes
[05:42] <pitti> as I said, that will work if you give me an additional conditions how to detect a mozilla-style package
[05:42] <carlos> pitti: I'm talking about giving you a fixed list of sourcepackages
[05:42] <pitti> no need to move gigabytes of OpenOffice stuff over, just because that happens to have a manifest file, too
[05:42] <carlos> pitti: isn't that enough?
[05:42] <pitti> carlos: ugly
[05:42] <asac> pitti: how about looking for locale lines in .manifest?
[05:42] <pitti> it won't allow us to easily add stuff to that list
[05:42] <asac> if they exist its likely a mozilla-style package
[05:43] <asac> you can even test if the locale line has 4 columns
[05:43] <pitti> isnt' there a typical directory name, or something like that?
[05:43] <asac> not really
[05:45] <asac> pitti: extensions have a install.rdf file
[05:46] <pitti> ah, now that's something
[05:46] <carlos> asac: does main firefox package have it too?
[05:46] <asac> no
[05:46] <asac> just extensions
[05:46] <asac> for moz apps we can only test if the .manifest file is in the chrome/ directory
[05:46] <carlos> asac: In fact, I think is more reliable to look for chrome.manifest for extensions, isn't that the name always? (except for xul applications)
[05:47] <asac> so either you find a install.rdf ... or one or more manifest files in a chrome directory ... is that good enough pitti ?
[05:47] <asac> carlos: i think pitti feares that there will be other packages shipping .manifest files
[05:47] <carlos> asac: well, he fears of looking for *.manufest
[05:47] <asac> which is why i suggested to also introspect those .manifest files and search for lines that start with ^locale and have 4 columns
[05:48] <carlos> chrome.manifest should be enough
[05:48] <asac> carlos: thats not given
[05:48] <carlos> ok
[05:48] <asac> look at dpkg -L firefox
[05:48] <pitti> asac: yeah, .../chrome/.../*.manifest sounds good to me
[05:48] <asac> pitti: its always directly in the chrome directory
[05:48] <pitti> ah
[05:48] <asac> so chrome/*.manifest
[05:48] <pitti> so, a test for chrome/*.manifest
[05:48] <carlos> asac: that's why I said that xul applications are an exception, it's only valid for extensions ;-)
[05:49] <asac> pitti: yes ... and if you have a install.rdf you have an extension package
[05:49] <pitti> asac: and fire firefox itself?
[05:49] <pitti> ah, ok
[05:49] <pitti> so "-e <arbitrary path>/chrome/*.manifest || -e ./install.rdf"
[05:50] <carlos> pitti: so that will give me that directory + all its content?
[05:50] <pitti> in this case I'll extract all *.manifest files and all files in their directories
[05:50] <pitti> (including subdirs, of course)
[05:50] <asac> pitti: yes, but thats all only valid for the binary tree
[05:50] <asac> (just to repeat)
[05:51] <pitti> that's quite a lot of non-trivial code for binarymangler, but bearable
[05:51] <asac> in source tree there is no chance to find something common
[05:51] <pitti> if it cannot be simplified, I'm ok with that
[05:51] <carlos> asac: we have that, if the extract script is run before cleaning the build directory
[05:51] <asac> ok
[05:51] <pitti> asac: oh, all rules need to be for the root directory of the built source tree
[05:51] <carlos> pitti: that means you don't need to look for .xpi files
[05:52] <pitti> ok
[05:52] <carlos> ok, so we had half task clear ;-)
[05:53] <carlos> asac: I need to talk with you about deploy translations from Launchpad
[05:53] <carlos> pitti: if you are busy you don't need to care about this part
[05:54] <carlos> asac: Is there any way to override mozilla translations without overwrite what you are installing right now?
[05:54] <carlos> for instance, If I want to ship a Spanish translation update for Firefox, is there a way to do it without overwriting /usr/lib/firefox/extensions/langpack-es-ES@firefox.mozilla.org/ directory content?
[05:55] <asac> carlos: well ... should be
[05:55] <asac> just /usr/lib/firefox/extensions/langpack-es-ES-rosetta@firefox.mozilla.org/
[05:55] <pitti> alright; so the rule from above makes everyone happy?
[05:55] <asac> and fill in previously not tranlsate strings
[05:55] <carlos> pitti: yes
[05:55] <pitti> carlos: did you already file a bug about this this morning?
[05:55] <carlos> pitti: no, not yet
[05:55] <pitti> ok
[05:56] <pitti> I'll create one
[05:56] <carlos> asac: yeah, I was thinking about using a Launchpad specific ID, although I would like to be able to change also existing translations in the other directory
[05:56] <carlos> asac: but I didn't find how Firefox looks for the translation directory
[05:57] <carlos> pitti: thank you
[05:58] <asac> carlos: what do we want to achieve? why don't we try to export complete translations from rosetta?
[05:58] <asac> will rosetta have the complete translations? if not, how does rosetta know the strings that need to be translated?
[06:00] <carlos> yes, we will have complete translations (or at least we should)
[06:00] <carlos> but we want to ship them inside language packs
[06:00] <carlos> so we cannot overwrite files from another package
[06:00] <carlos> like mozilla-firefox-locale-es-es
[06:01] <carlos> and we still need them built to get updates from upstream
[06:01] <asac> hmm
[06:01] <carlos> asac: if it's a single file (like .mo ones for gettext applications) is quite trivial to remove them from the binary packages, but in this case, is not so trivial...
[06:01] <asac> ok, so we need two packages anyway?
[06:02] <carlos> asac: yeah, you keep current ones, although the updates will be included in the standard existing language packs ones
[06:02] <asac> will rosetta automatically package a locale package for me?
[06:02] <carlos> yes, that's the idea
[06:02] <asac> or will i have to include translations that are somehow dumped from it
[06:02] <carlos> you need to keep packaging whatever is in upstream, though
[06:02] <carlos> no, you don't need to care about Rosetta
[06:03] <carlos> that's why I need to know how to override translations from upstream
[06:04] <asac> carlos: i don't think you can reliably override ... would be more or less at random. so lets just fill in the gaps
[06:04] <asac> is that enough?
[06:04] <asac> e.g. only export entities that don't exist?
[06:05] <carlos> that prevents us to fix broken translations
[06:05] <carlos> and will be a bit confusing
[06:06] <carlos> maybe we could do something like we did with glibc to check first in language pack translations and then fall back into the standard translations...
[06:06] <carlos> but in Firefox
[06:06] <asac> how about just removing all .jars in binarymanagler from language packs?
[06:07] <asac> so all translations will live in our -rosetta packages?
[06:07] <asac> e.g. mozilla-locale-de will be more or less empty ... and depend on mozilla-locale-de-rosetta
[06:07] <carlos> asac: will not that break having manifest files pointing to a non existing file?
[06:08] <asac> carlos: since manifests need to be in -rosetta as well, we should drop them as well
[06:08] <asac> e.g. rm *.jar *.manifest :)
[06:08] <carlos> pitti: we need you here again...
[06:08] <carlos> that's done in pitti's land so he's the one to answer that question
[06:09] <carlos> asac: btw, what's /var/lib/mozilla-firefox/extensions.d directory for ?
[06:09] <asac> thats old ... you can ignore it
[06:09] <carlos> seems like you are able to give a priority to the extensions...
[06:09] <carlos> ok
[06:10] <asac> no its not used anymore
[06:10] <carlos> ok
[06:11] <carlos> asac: how does Firefox know about which language pack use? where is noted that?
[06:11] <carlos> does it iterates over all extensions available on /usr/lib/firefox/extensions and your home directory?
[06:12] <asac> carlos: it loads all extensins that way ... right
[06:12] <asac> then it resolves all locale/ uris with the locale found in OS environment
[06:12] <carlos> so that's why you say it's random?
[06:12] <asac> more or less yes.
[06:12] <carlos> it depends on which directory picks first?
[06:12] <carlos> ok
[06:12] <asac> there are other source of randonmenss as well
[06:13] <carlos> that sounds sooo broken
[06:13] <asac> for instance stuff gets indexed in hash maps ... so order gets lost
[06:13] <carlos> I see
[06:13] <asac> welll overwriting locales isn't really a strong usecase :)
[06:13] <asac> maybe for us, but not for others
[06:13] <pitti> re
[06:14] <pitti> https://bugs.edge.launchpad.net/ubuntu/+source/pkgbinarymangler/+bug/149017
[06:14] <ubotu> Launchpad bug 149017 in pkgbinarymangler "extract Mozilla-ish translations" [Undecided,New] 
[06:14] <pitti> can you please scrutinize the description again and give your ack in the bug report?
[06:14] <carlos> pitti: we need to figure a way to remove Mozilla translation files like we do with .mo files
[06:14] <carlos> pitti: sure...
[06:14] <pitti> carlos: oh, why?
[06:14] <pitti> carlos: do the extensions ship their own translations?
[06:14] <carlos> pitti: because there is no way to override upstream ones installed
[06:15] <carlos> pitti: yeah, and also, language packs from upstream need to be still built and uploaded to Ubuntu's archive so we are able to keep Launchpad update
[06:15] <carlos> updated
[06:15] <pitti> btw, this rule does not really work with https://pastebin.canonical.com/461/
[06:16] <pitti> well, it would just copy the entire source and build tree
[06:17] <carlos> pitti: if that bug description covers this:
[06:17] <carlos> /usr/share/firefox/chrome/en-US.jar
[06:17] <carlos> /usr/share/firefox/chrome/en-US.manifest
[06:17] <carlos> yes, that's it (I'm not sure I'm understanding it completely)
[06:17] <carlos> pitti: which is ok
[06:18] <carlos> pitti: Launchpad will discard the files that are not related with localisation
[06:18] <pitti> carlos: it won't cover /usr
[06:18] <pitti> it will pick up ./debian/foo/usr/share/firefox/chrome/en-US.{jar,manifest}, though
[06:18] <carlos> pitti: yeah, sorry, /debian/foo/usr/...
[06:20] <asac> pitti: its best to remove all translations from locale packages if we want to support translation fixes from rosetta
[06:20] <asac> i don't feel so good about that ... i would prefer just to fill the gaps and if we have improvements send them upstream
[06:21] <asac> regularly
[06:21] <carlos> asac: my only concern about removals is that, if we have a package like ubufox including 'es-ES' or 'de' translations, how would we handle that?
[06:22] <carlos> asac: that's not the way it works for other applications and will be confusing (although we ask translators to do what you just said, send changes and new translations to upstream)
[06:22] <asac> carlos: you have to import initial entities anyway ... regardless if there is en-US or something else
[06:23] <carlos> asac: I'm talking about content removal
[06:23] <asac> ah ok
[06:23] <carlos> the import into Launchpad is completely clear, don't worry
[06:23] <asac> carlos: languages included in application/extension just cannot be changed through rosetta i guess
[06:23] <asac> we won't remove en-US from firefox as well
[06:24] <carlos> asac: right, en-US should stay in all cases
[06:24] <carlos> pitti: are you happy with the removal policy?
[06:25] <asac> yes, so lets say: all translations that are in the _main_ packages have to stay
[06:25] <asac> so only pure locale packages are stripped
[06:25] <carlos> pitti: it would mean to remove the manifest and .jar files for all extensions (the ones that have install.rdf)
[06:25] <asac> (for all pure locale extensions only though)
[06:26] <carlos> asac: I will document that corner case and see whether we could figure a way to solve that later, once the initial support is in place
[06:26] <pitti> I did not follow scrollback, sorry; reading (thousand things today, crazy)
[06:26] <asac> carlos: right
[06:26] <pitti> carlos: so, please give me a rule which pkgbinarymangler shuold exercise (which files, etc0
[06:26] <pitti> I don't see any rule above, which files to remove
[06:27] <carlos> pitti: so you only remove files (chrome.manifest and *.jar) from packages that have install.rdf inside it
[06:27] <asac> carlos: for ubufox i would prefer to only use rosetta locales (except for en-US) ... so thats not such a corner case.
[06:27] <carlos> asac: however, will not that break other extensions that are not translation ones?
[06:27] <carlos> asac: talking about the rule I gave to pitti
[06:27] <asac> carlos: yes ... only remove files from _pure_ locale packages
[06:27] <carlos> asac: so how do we detect that?
[06:27] <asac> never ever remove something for other packges
[06:28] <asac> source package name should include -locale-all :)
[06:28] <carlos> pitti: is that enough to you?
[06:28] <pitti> that's fine for me (except for gutsy, of course)
[06:28] <pitti> and what shall I remove?
[06:28] <carlos> pitti: sure, this is only possible for Hardy
[06:29] <carlos> pitti: chrome.manifest and *.jar
[06:29] <carlos> asac: correct? ^^^
[06:29] <pitti> so I should change the gutsy pkgbinarymangler to extract the translations, and the first hardy one to remove them, right?
[06:29] <asac> pitti: if source package is -locale-all ... remove all *.jar and *.manifest
[06:29] <pitti> but I still don't see the purpose here
[06:29] <asac> pitti: oh and install.rdf :)
[06:29] <pitti> wouldn't that make the -locale-all packages essentially empty?
[06:29] <asac> pitti: actually remove all files taht are not directories
[06:30] <carlos> pitti: yeah, I guess is like kde-i18n one
[06:30] <pitti> why would we need to ship them still?
[06:30] <pitti> hm
[06:30] <asac> pitti: those locale packages need to be completely empty and in turn depend on $pkgname-rosetta
[06:30] <carlos> so source should be in main, binaries in universe
[06:30] <asac> pitti: because we have to build them in order to import upstream entities
[06:30] <pitti> hm, I thought we would ship them in the normal language-packs
[06:30] <carlos> pitti: yeah, that's what asacmeans with $pkgname-rosetta
[06:30] <asac> pitti: we need a source to automatically import upstream entities
[06:31] <asac> however _if_ we want to option to replace already translated entities we have to wipe everything from them and depend on the -rosetta package
[06:32] <asac> pitti: do i need to rephrase?
[06:32] <pitti> right
[06:33] <pitti> in the long run it would probably be better to import those straight into rosetta (kde-i18n and upstream mozilla translations)
[06:33] <pitti> but ok for now
[06:33] <asac> pitti: well its for hardy anyway ... so lets just import them straight
[06:33] <asac> that sounds more reasonable
[06:33] <carlos> pitti: do you mean using an external process to fetch them automatically?
[06:34] <carlos> asac: we don't have such process available yet, so it's not possible
[06:34] <pitti> carlos: we can already upload po files and tarballs into Rosetta in the UI, right?
[06:34] <carlos> I mean, automatically
[06:34] <pitti> that can certainly happen with a script or wget call, etc.
[06:34] <asac> carlos: well its just a small step to automize it ... and even if we can't doing it manually from time to time is good enough as well i guess
[06:35] <carlos> asac: believe me, you will get bored of that
[06:35] <carlos> I'm doing it manually for debian-installer
[06:35] <asac> carlos: i won't do it :)
[06:35] <carlos> asac: that's why you suggest it ;-)
[06:35] <asac> hehe
[06:35] <asac> but pitti says it ... you can setup a script for that
[06:36] <carlos> pitti: I would prefer to keep doing it this way and expand our XML-RPC to do that automatic process you talk about (we have a spec to offer such XML-RPC api for products)
[06:36] <asac> ok ... so we have a procedure to extract translatable strings during build ... and then we can fill rosetta by manually (scripted) importing upstream translations regularly
[06:36] <pitti> carlos: ok
[06:36] <asac> is that correct?
[06:36] <carlos> asac: kind of, yes
[06:37] <carlos> ok, I think I have everything clear (or kind of and I could start working now)
[06:37] <carlos> pitti: don't deploy this yet, though
[06:38] <carlos> pitti: I will need to add support to Launchpad first or we will get untranslated Firefox/Firebird
[06:38] <asac> ok ggreat
[06:38] <carlos> pitti: also, remember of doing the removal only for main packages
[06:39] <carlos> asac: I guess the output I should provide is the exact content of packages like mozilla-firefox-locale-es-es, right?
[06:39] <pitti> can you please add the removal rules to the bug above?
[06:39] <carlos> pitti: sure
[06:40] <pitti> since especially the removal won't happen before hardy
[06:40] <asac> carlos: well ... if we have to build a package from that anyway, you can also export .xpi files
[06:41] <asac> carlos: but i thought you rosetta uploads .debs automatically ;)
[06:41] <carlos> asac: you don't need to do that, pitti's scripts will handle everything, the export and deployment is transparent to you
[06:42] <asac> ok ... then whatever works is fine with me :)
[06:42] <carlos> asac: not exactly, just checking what we should deploy ;-)
[06:42] <carlos> ok
[06:42] <asac> its important the the .xpi content is just in a directory inside /usr/lib/firefox/extensions ... and the directory name is the same as the em:id in the install.rdf
[06:43] <carlos> ok
[06:43] <carlos> pitti, asac: That's all from me. Thank you for your help. Do you have anything else you want to talk about?
[06:43] <asac> so if you use em:id rosetta-de@locales.firefox.ubuntu.com ... its /usr/lib/firefox/extensions/rosetta-de@locales.firefox.ubuntu.com
[06:43] <asac> carlos: no ... not atm
[06:44] <asac> carlos: just wonder if we can get translations for ubufox right now :)
[06:44] <asac> carlos: even if we have to do export et al manually ...it would be great
[06:44] <asac> but i htink its just too late for that
[06:44] <carlos> asac: I need to fix our import code to be able to deal with its layout and implement the export code to be able to deploy it
[06:44] <asac> ok
[06:44] <asac> no problem
[06:44] <pitti> asac, carlos: removal> wouldn't it be more suitable to just change the -locale-all packages? there aren't that many
[06:44] <carlos> asac: however, we could add it post release
[06:45] <pitti> and they are quite complicated, since they shuffle, unpack, patch a lot of files
[06:45] <asac> pitti: how?
[06:45] <pitti> if we are just trashing them, wouldn't it be easier to just have them unpack all the files without producing a lot of binary packages?
[06:45] <asac> pitti: actually if we import the .xpi manually to rosetta we won't need the locale-all packages anymore imo
[06:45] <pitti> asac: that's what I think, too
[06:46] <carlos> pitti: so once the extract script is executed, they execute a rule that produces an empty binary?
[06:46] <asac> pitti: yes, i would be fine ... is it possible to have a source package that doesn't produce any binary package?
[06:46] <pitti> no, that doesn't work
[06:46] <asac> pitti: anyway ... i think we won't need that package at all once .xpi are important
[06:46] <asac> imported
[06:46] <carlos> pitti, asac: Ok, I will see whether we could speed the XML-RPC changes needed to do that
[06:47] <pitti> carlos: using the existing import form in the LP UI doesn't work?
[06:47] <asac> carlos: yeah ... otherwise we can write a custom client for that
[06:47] <carlos> asac: is there a fixed URL for those .xpi language packs? I guess the answer is yes...
[06:47] <asac> yes
[06:47] <pitti> no, per-version
[06:47] <pitti> oh?
[06:47] <pitti> some /trunk or /nightly directory?
[06:47] <asac> http://releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.7/linux-i686/xpi/
[06:47] <carlos> pitti: yeah, as a workaround we could do that
[06:47] <pitti> so, per-version
[06:48] <asac> yes
[06:48] <asac> i htink a tool like:
[06:48] <carlos> but the web form could change over time, and I don't want to run a script with my credentials or any other credentials
[06:48] <asac> import-xpis-to-rosetta.sh firefox 2.0.0.7
[06:48] <asac> would be good
[06:48] <asac> replace the name of the script with something reasonable
[06:48] <carlos> yeah, but s/import-xpis-to-rosetta.sh/import-xpis-to-launchpad.py/
[06:48] <carlos> :-P
[06:49] <carlos> I will talk with Danilo and Jeroen to see what could be done, ok?
[06:50] <asac> sure
[06:50] <asac> thanks
[06:51] <carlos> pitti, asac: Ok, thanks for everything, I will keep you updated with my discussion with Jeroen and Danilo
[06:51] <carlos> cheers
[06:51] <pitti> thanks
[07:03] <cwong1> asac: do you have the time to chat now?
[07:04] <cwong1> asac: looks like sport time for you. Will catch you later.. :)
[07:05] <asac> cwong1: grocery store ... supermarket
[07:05] <asac> i think 60 minutes
[07:05] <cwong1> ok :)
[07:58] <Admiral_laptop> bug 149004
[07:58] <ubotu> Launchpad bug 149004 in mythbuntu "Xfce4 splash screen causes login to hang" [Medium,Confirmed]  https://launchpad.net/bugs/149004
[07:58] <Admiral_laptop> hmm, thats not it
[08:07] <asac> cwong1: ok
[08:08] <cwong1> asac: welcome back
[08:08] <cwong1> asac: few things I want to talk to u
[08:09] <asac> i currently look into the menu issue. currently debugging the layout engine
[08:09] <cwong1> asac: ok.
[08:09] <asac> appears to be that in the beginning the positioning is relative to real 0,0 ... after using popup its relative to the window 0,0
[08:09] <cwong1> asac: gconf: i found it in extension. Is it enable by default?
[08:10] <asac> no ... you have to set some preference
[08:10] <cwong1> in configure.in
[08:10] <cwong1> ?
[08:10] <asac> its important that we build gnome-support for that
[08:10] <asac> cwong1: no ... a .js setting
[08:10] <cwong1> ok
[08:10] <cwong1> I will look for it
[08:11] <asac> cwong1: you need to enable gnome support ... for that you need libgnomeui-dev installed during build from what i know
[08:11] <cwong1> asac: ok
[08:11] <asac> cwong1: just try to build with libgnome2-dev
[08:11] <cwong1> asac: I will work on this
[08:11] <asac> if that works we should just add the properl build-depend to the debian/rules
[08:12] <asac> aeh debian/control ;)
[08:12] <cwong1> asac: ok
[08:12] <cwong1> asac: hildon stuff
[08:12] <asac> yeah ... you found panning support?
[08:13] <cwong1> asac: In minio.  I think fbreader has that support too. I will look into that
[08:13] <cwong1> asac: regarding "App Loading" popup, we need to use libosso
[08:13] <asac> ok ... if you found a pointer on how they do it let me know
[08:14] <asac> cwong1: ok ... i didn't see any app that works ... calculator animation stops before the app comes up as well
[08:14] <cwong1> asac: gcal does work.  All we have to do is to make a call to osso_initialize.  I can add that to our startup code.
[08:15] <asac> cwong1: which startup code do you refer to?
[08:16] <cwong1> asac:  midbrowser/componetns/nsBrowserxxxx.cpp
[08:16] <asac> ah ok
[08:16] <asac> yes ... if that works, its ok to do it at that place
[08:16] <cwong1> did u get a chance to look what it takes to bring the browser window visible
[08:17] <cwong1> My XRaiseWindow doesnt't work,  Other app simply do a gtk_window_present and work just fine.
[08:17] <asac> nope ... i think you put the XRaiseWindow in the wrong place ... e.g. on client side
[08:17] <asac> we have to put that or gdk_window_present on the receiving side
[08:17] <asac> e.g. where the browser processes the "open tab"
[08:18] <cwong1> in nsWindow.cpp?
[08:19] <asac> no idea if we want to raise the window whenever there is a new tab opened
[08:19] <asac> i thought just where the X message to open a new tab is retrieved
[08:20] <cwong1> ok, I will look into it some more.
[08:20] <cwong1> on flash plugin?  are you going to fix the install path in the flashplugin?
[08:21] <asac> i think XRemoteService.cpp is a good start
[08:21] <cwong1> ok
[08:21] <asac> cwong1: that should be done already
[08:21] <asac> isn't it?
[08:21] <asac> i have
[08:21] <asac> /usr/lib/midbrowser/plugins/flashplugin-alternative.so
[08:22] <cwong1> ok I will double check.
[08:22] <cwong1> should we modified our code to also look for plugin in firefox directory?
[08:22] <cwong1> s/modified/modify/
[08:23] <asac> cwong1: not for gutsy ... in hardy we will have to go for firefox 3/xulrunner-1.9 ... by that time we will share the same directory anyways
[08:23] <cwong1> ok
[08:23] <asac> for now i would just stick to use the midbrowser/plugins directory
[08:23] <cwong1> that's all I have.
[08:24] <asac> ok great ... i will look into popup further ... and in anycase bake a release at the end of the day
[08:24] <cwong1> great. tx
[08:24] <asac> so tomorrow we will have an upload ... for whatever we have by then
[08:24] <cwong1> k
[08:56] <gnomefreak> this is aways a good fucking sign Sorry, the program "firefox-bin" closed unexpectedly
[08:56] <gnomefreak> Your computer does not have enough free memory to automatically analyze the problem and send a report to the developers.
[08:56] <gnomefreak> i have plenty just today seems to be very hard on CPU
[08:58] <Ubulette> lo
[09:06] <Ubulette> gnomefreak, ff2 ?
[09:06] <gnomefreak> yeah
[09:07] <Ubulette> run it with -g
[09:07] <gnomefreak> Ubulette: no becasue next run opened
[09:07] <gnomefreak> so its non producible atm
[09:08] <Ubulette> (I should improve ff3 for that. -g is no longer there)
[09:39] <gnomefreak> tonyyarusso: good hang out in here
[09:39] <tonyyarusso> gnomefreak: always do
[09:40] <gnomefreak> asac: Admiral_laptop if you see a nick that has iarc in any part of it please ping me or tonyyarusso if we are not here ping staff (i think nalioth is in #ubuntu-mobile he is staffer that has been klineing them
[09:40] <asac> gnomefreak: he?
[09:41] <gnomefreak> they are logging all channels publicly and there are a shit load of them
[09:41] <gnomefreak> nalioth has been klining them for a while now
[09:41] <gnomefreak> believe me you dont want public logs if you can help it
[09:41] <asac> gnomefreak: we log this channel anyways
[09:42] <asac> at least we have ubuntulog here :)
[09:42] <gnomefreak> asac: http://www.ircarc.com/
[09:42] <gnomefreak> you dont want it that public
[09:43] <gnomefreak> ours are somewhat public if you know what you are looking for.
[09:43] <gnomefreak> with them it can end up anywhere
[09:43] <asac> still don't see the point :)
[09:43] <asac> anyway ... feel free to kick whatever bot you wanna kick ;)
[09:43] <gnomefreak> hey staff told us to do it just letting you know
[09:44] <asac> which staff? freenode?
[09:44] <gnomefreak> shit i had him in -ops earlier today and i got caught up in that email and forgot :(
[09:44] <gnomefreak> yes freenode
[09:45] <gnomefreak> tonyyarusso: if you see jdong please ping me
[09:45] <tonyyarusso> gnomefreak: 'k
[09:46] <Admiral_laptop> gnomefreak: can do
[09:46] <gnomefreak> ty
[09:46] <Admiral_laptop> iarc...
[09:46] <gnomefreak> it may have letter in front or back
[09:47] <Admiral_laptop> i'll keep an eye out
[09:49] <Ubulette> gnomefreak, this channel and many others are archived by fabbione too
[09:49] <gnomefreak> Ubulette: yes i know again its differnet
[09:49] <Ubulette> why ?
[09:50] <asac> i don't see the difference either ;)
[09:50] <asac> maybe the difference is that they don't ask, but just log  and thus freenode staff wants to get rid of them
[09:52] <Ubulette> asac, a8 ?
[09:52] <Ubulette> not today ?
[10:05] <asac> Ubulette: i wonder how i can make diff against ppa generic
[10:05] <asac> for xul ...
[10:06] <Ubulette> ?
[10:06] <asac> i test atm if there is cvs or mt in version ... otherwise i disable system-ns**
[10:06] <Ubulette> oh
[10:06] <asac> only problem is the versioned depends on libnss/nspr
[10:06] <asac> because its not available
[10:06] <Ubulette> then do control.in
[10:07] <asac> i could just drop the versioning ... and take for granted that ppa will have new
[10:07] <asac> yeah ... but is it worth it?
[10:07] <Ubulette> don't think so.
[10:07] <asac> i mean is it worth to use control.in over just relaxing build depends on libnspr/nss
[10:07] <asac> we could do the test in rules even :)
[10:07] <asac> i think i will do that
[10:08] <Ubulette> it's just do it manually this time, we'll figure out something
[10:08] <Ubulette> -it's
[10:48] <Ubulette> gnomefreak, u dont like automatix ? :)
[10:49] <gnomefreak> Ubulette: i have seen what it does to users pcs. i am not personal about it at all
[10:49] <gnomefreak> Ubulette: but in the support channels you see alot of fucked up systems due to it
[10:51] <Ubulette> asac, do you need help for that a8 rollout ?
[11:41] <asac> Ubulette: yeah ... it fails because it wants to create mozilla-nspr.pc
[11:41] <asac> Ubulette: ok i found the patch
[11:50] <Ubulette> asac, can I see a diff ?
[12:11] <asac> Ubulette: http://paste.ubuntu.com/613/
[12:12] <Ubulette> is that xul of ff ?
[12:12] <asac> xul
[12:12] <Ubulette> hmm, I've done that already, no ?
[12:13] <asac> nope
[12:13] <asac> it wasn't complete
[12:13] <asac> you forgot -nspr and -nss hunks
[12:14] <asac> because they are not used when SYSTEM_NSPR /NSS
[12:14] <Ubulette> hm, it was intentional for our nss/nspr.
[12:14] <Ubulette> maybe you need that.
[12:14] <asac> i doubt that it was intentional ... it was just not needed, because that code isn't used for system
[12:15] <Ubulette> so it's just install_pkgconfig_files_with_version.patch + lines 25/26, right ?
[12:16] <asac> in paste: 24-27 and 35,36
[12:16] <asac> but yes, i updated the install_pkgconfig_files patch
[12:16] <Ubulette> is that the only change you've made compared to .dev ?
[12:16] <asac> no
[12:17] <asac> but not much
[12:25] <Mirv> asac: Hi, again the bug 139380 regarding localization. I put a new attachment now there, after finding out about the escaped unicode that should be used for the properties file. I can get the translations working, but only if I overwrite the locale/en-US dir with those files. Anyway, could you add that locale/fi-FI directory to ubufox sources and try to find out why the translations aren't used from the correct locale?
[12:25] <ubotu> Launchpad bug 139380 in ubufox "Untranslated strings in ubufox" [Undecided,Confirmed]  https://launchpad.net/bugs/139380
[12:25] <asac> Mirv: did you add that locale to chrome.manifest?
[12:26] <Mirv> asac: oh!
[12:28] <Mirv> asac: thanks, now it works! I also added the modified chrome.manifest to the bug report now.
[12:40] <Ubulette> asac, fyi, a9pre is showing a few glib/gdk warnings on shutdown since the last few days: http://paste.ubuntu-nl.org/39593/
[01:10] <asac> but not with a8
[01:10] <asac> ?
[01:10] <asac> Ubulette: or is it a gtk regression?
[01:11] <Ubulette> I don't know
[01:11] <Ubulette> not with a8 for sure.