[05:38] <CheGuevara> bug #186186
[05:38] <ubotu> Launchpad bug 186186 in xulrunner-1.9 "web page background render errors" [High,Confirmed] https://launchpad.net/bugs/186186
[05:38] <CheGuevara> shouldn't this be marked as fixed
[07:02] <[reed]> ugh
[07:02] <[reed]> some people are idiots
[07:02] <[reed]> what is with these people
[07:03] <[reed]> I just happened to stop and read the changelog for a package update I was getting for acpi-support
[07:03] <[reed]> and I looked into some of the bugs mentioned that were Thinkpad related
[07:03] <[reed]> since they concerned me
[07:04] <[reed]> turns out, they were removing some (now unneeded) files, but the removals only affected _new users_ of the package
[07:04] <[reed]> and not current users
[07:04] <[reed]> so, all current users were still screwed
[07:04] <[reed]> since they now had old config files for acpi
[07:04] <[reed]> that were wrong
[07:04] <[reed]> and broke stuff
[07:04] <[reed]> with no way of knowing that they needed to remove some files
[07:04] <[reed]> idiots
[07:08] <[reed]> I'd love to smack these people with some clue-by-fours
[07:13] <[reed]> maybe I'm being too tough, but I guess I was just hoping people knew better
[08:43] <fta> hi
[08:44] <fta> asac, please have a look at bug 202874
[08:44] <ubotu> Launchpad bug 202874 in prism "Please sponsor prism 0.8+svn20071115r8030-0ubuntu2" [Undecided,New] https://launchpad.net/bugs/202874
[08:44] <asac> [reed]: yeah ... i know what you feel
[08:46] <[reed]> This is just one reason why so many people recommend complete reinstalls for all distro upgrades
[08:46] <[reed]> because people forget to think about the current users
[08:47] <[reed]> and only think about new users
[08:47] <asac> [reed]: right. fixing config file can be quite hard
[08:47] <asac> which package?
[08:47] <[reed]> acpi-support
[08:47] <[reed]> so, they removed two files from /etc/modprobe.d
[08:47] <[reed]> but they only removed the files in the package... they didn't do anything to remove the files for people who already have them in place
[08:48] <[reed]> :(
[08:48] <[reed]> so, all current users are screwed
[08:48] <[reed]> since they will never know they need to remove those files
[08:48] <[reed]> https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/193842/comments/17
[08:48] <ubotu> Launchpad bug 193842 in acpi-support "Please sponsor cherrypicked fixes for acpi-support into Hardy" [Medium,Fix released]
[08:49] <[reed]> I might have been a bit too ranty
[08:49] <[reed]> was just a bit aggravated that they didn't think about current users
[08:49] <asac> [reed]: if they are below /etc/ ... they should check if you have modified them
[08:49] <asac> and if so, keep them ... oherwise remove them
[08:49] <[reed]> yeah, they didn't do that
[08:49] <[reed]> ;)
[08:49] <asac> and right ... they won't get removed automatically
[08:52] <asac> fta: you need to get an ack for this version update from ubuntu-release
[08:52] <asac> i can ack the debdiff to be ok, but not the FF exception
[08:53] <asac> so, include a rational why its required for hardy and subscribe motu-release
[08:54] <asac> fta: btw, nice nick :)
[08:54] <asac> could you take it over due to inactivity?
[08:55] <fta> it's universe, motu guys said it's not needed
[08:55] <asac> really?
[08:55] <asac> i don't think so
[08:56] <asac> it still needs a  FF exception
[08:56] <asac> thats why motu-release exists
[08:56] <fta> rationale is easy: it fixes all the bugs reported so far
[08:56] <asac> fta: ah its not a new upstream version?
[08:56] <fta> here, dholbach reviewed it, he just wants you to review debian/patches/remove_scriptableio.patch
[08:57] <asac> then you don't need FF exceptoin indeed
[08:57] <fta> it's not a new version
[08:57] <asac> yes, i read that
[08:57] <asac> why did IO.getFile work?
[08:58] <[reed]> hmm, I remember when scriptable IO was removed... It really broke places
[08:58] <[reed]> ;)
[08:58] <asac> ok
[08:58] <[reed]> had to write a patch to fix that
[09:00] <fta> mozilla bug 423334
[09:00] <ubotu> Mozilla bug 423334 in General "crash at startup in NS_CompareVersions" [Critical,New] http://bugzilla.mozilla.org/show_bug.cgi?id=423334
[09:00] <fta> got that yesterday
[09:01] <asac> fta: no idea, but i think the name of exported symbols should be more scoped like WebAppInstallFileIO instead of FileIO ... otherwise its fine
[09:02] <fta> the name is not mine, it's from prism
[09:03] <fta> i have to go. see you.
[09:03] <asac> fta: but you introduce it, don't you?
[09:03] <asac> is that from a bug?
[09:04] <asac> k
[09:04] <asac> cu
[09:04] <fta> prism has it too now since xul dropped scriptable IO
[09:04] <asac> fta: so its a patch you cherry picked from upstream?
[09:04] <fta> mostly
[09:05] <fta> from several commits
[09:05] <fta> i had to redo everything as files has been renamed and content reorganized
[09:05] <fta> have
[09:06] <fta> out
[09:11] <asac> fta: ok. please document where patches come from in future. acking for now
[10:30] <asac> jetsaredim: tomorrow i plan to upload a bunch of extensions. are there any more you want (or maybe that you don't want) to be processed in this first batch?
[12:16] <asac> jtv: high. carlos is on holidays right?
[12:16] <asac> ;)
[12:16] <asac> s/high/hi/
[12:16]  * asac isn't high ;)
[12:17] <jtv> asac: right
[12:17] <jtv> about the holidays, I mean.
[12:17] <asac> hehe
[12:17] <asac> i think we found a few bugs in the export/import script
[12:17] <jtv> ?
[12:18] <asac> there are a few .properties files not included that exist in the en-US.xpi
[12:18] <asac> e.g. there is no reference for them in the .pot file
[12:18] <jtv> (you mean "i.e.", right?)
[12:18] <jtv> Forgive my pedantry.  Any idea what makes those files special?
[12:19] <asac> jtv: i can't see anything except that they live deeper in the tree
[12:19] <asac> xulrunner/en-US.xpi/en-US.jar!/locale/en-US/necko/necko.properties
[12:19] <jtv> Ahhh...
[12:19] <asac> ^^^ thats included
[12:20] <jtv> Then I guess there's no directory traversal inside the jar file?
[12:20] <asac> http://paste.ubuntu.com/5769/
[12:20] <asac> those are not
[12:20] <asac> jtv: the one above is in a .jar too
[12:20] <asac> so i think its just how deep you descent
[12:21] <asac> hmm
[12:21] <asac> its the same depth
[12:21] <jtv> Not inside the jar file.
[12:21] <asac> there is one .dtd file missing as well
[12:21] <jtv> The ones that fail are nested one directory deeper inside the jar file.
[12:21] <asac> xulrunner/en-US.xpi/en-US.jar!/locale/en-US/global/brand.dtd
[12:21] <asac> jtv: ok .. then my guess was right
[12:21] <asac> just bad eyes atm ;)
[12:22] <jtv> Your diagnosis looks correct to me.
[12:22] <asac> for the brand.dtd i have no idea though
[12:22] <jtv> IIRC some things about the directory structure are still hard-coded.
[12:22] <jtv> Carlos is working on actually parsing the manifest file.
[12:23] <jtv> Is this something you can work around?
[12:23] <asac> jtv: ok. you should just look at all .properties and .dtd files (and thats what i thought is supposed to happen already)
[12:23] <asac> jtv: no
[12:23] <asac> jtv: we need translations for those
[12:23] <asac> and we cannot move them somewhere else
[12:23] <asac> (inside the jar)
[12:23] <jtv> :-/
[12:23] <asac> jtv: you don't need to parse the manifest
[12:23]  * jtv looks up the code
[12:23] <asac> just every .properties and .dtd
[12:24] <asac> jtv: i am already parsing the manifest in the exporter. so in next release you can reuse my code i guess
[12:24] <jtv> Well, the manifest has useful extra information.  Divining a correct language code from a filename can involve some ugly guesswork.
[12:24] <asac> jtv: the language code is taken from the .xpi
[12:24] <jtv> I don't suppose the parsing of the file itself is a problem, more how to make it drive the scanning of the XPI file.
[12:25] <asac> it should not be taken from the file path ... and afaik thats how it works
[12:25] <asac> (at least carlos told me iirc)
[12:25] <jtv> It takes it from the XPI file's name right now, but that's not really right because one XPI file can contain multiple languages.
[12:25] <asac> jtv: yes. but for now we provide perfect .xpi files (e.g. only en-US translations included)
[12:25] <asac> ... e.g. so i fix it on the package build side
[12:25] <jtv> asac: just a moment, I'll look up the directory traveral code.
[12:26] <asac> jtv: yes. but our exporter now guaruantees to provide clean .xpi files
[12:26] <asac> (e.g. to overcome this issue)
[12:26] <asac> jtv: thanks
[12:31] <jtv> asac: hmm... coming back on that nesting-depth thing.  I don't see any trace of hard-coded directory structures.
[12:32] <jtv> It seems to go through all .dtd and .properties files regardless of location.  They can even be directly in the XPI file instead of in a jar file, or in a jar file inside a jarfile etc., AFAICS
[12:33] <asac> jtv: do you have the en-US.xpi that we use?
[12:33] <asac> maybe there is an exception when running it
[12:33] <jtv> no
[12:33] <jtv> Can you point me to it?
[12:33] <asac> http://people.ubuntu.com/~asac/en-US.xpi
[12:34] <asac> jtv: ^^
[12:34] <asac> jtv: http://people.ubuntu.com/~asac/xulrunner.pot ... thats what came out of it
[12:35] <jtv> asac: forbidden
[12:35] <jtv> asac: can't access either.
[12:35] <asac> oh
[12:35] <asac> let me check permissions
[12:35] <asac> jtv: try again
[12:36] <jtv> success
[12:36] <asac> jtv: http://paste.ubuntu.com/5770/
[12:37] <asac> those are all files (with comments)
[12:37] <asac> only properties and dtd files are a problem here
[12:37] <asac> the rest needs to be sorted later
[12:37] <jtv> Well those are the only ones we parse...
[12:37] <asac> right
[12:38] <asac> jtv: the comments are not written for you (in case you wonder) ... thats what i explained to the guy that prototypes the po2xpi
[12:38] <jtv> asac: I do see strings from the files in your list of missing properties files.  What am I doing wrong?
[12:39] <asac> jtv: which?
[12:39] <asac> give me an example so i can check
[12:39] <jtv> for example:
[12:39] <jtv> #: xulrunner/en-US.xpi/en-US.jar!/locale/en-US/global-platform/win/accessible.properties:3(check) msgid "Check" msgstr ""
[12:39] <jtv> Ahem.  Imagine some line breaks there.
[12:39] <asac> yeah
[12:39] <asac> let me check
[12:39] <jtv> Isn't that one of the files you said were missing?
[12:40] <asac> jtv: well ... might be a bug in the script i wrote
[12:40] <asac> jtv: xulrunner/en-US.xpi/en-US.jar!/locale/en-US/global-platform/unix/intl.properties
[12:40] <asac> thats definitly missing
[12:41] <asac> jtv: oh
[12:41] <jtv> ?
[12:41] <asac> jtv: the one above should exist for unix/
[12:41] <asac> appears that the list i posted is right
[12:42] <asac> the win/ ones exist, but the unix ones don't
[12:42] <asac> but appears to be random which one exist
[12:42] <jtv> I don't see the win ones either.
[12:42] <jtv> But my next guess is: encoding problem.
[12:42] <jtv> Maybe the mac versions happen to be in UTF-8.
[12:42] <asac> platformKeys.properties exists for max
[12:42] <asac> mac
[12:42] <asac> but not for win+unix
[12:42] <jtv> I notice that unix/intl.properties contains only one string, and it's an ellipsis.  Not an ASCII one.
[12:43] <jtv> And the charset is specified as Latin-1...  Does that even have an ellipsis?
[12:43] <asac> jtv: lets look at accessible.properties
[12:43] <asac> in pot there is the one you posted above (win)
[12:43] <asac> but no mac nor the unix one
[12:43] <asac> (in case intl.properties really has special encoding)
[12:44] <jtv> Ahh,, I think I know!
[12:44] <asac> jtv: maybe it just uses the filename as a key?
[12:44] <jtv> The file paths are attached to individual strings.
[12:44] <jtv> And the strings are identical!
[12:44] <asac> and thus wipes whatever comes first?
[12:44] <asac> right
[12:44] <asac> so the key are duplicates?
[12:44] <jtv> Exactly.
[12:45] <asac> jtv: ok lets look at brand.dtd
[12:45] <asac> is there a duplicate as well?
[12:45] <jtv> looking...
[12:45] <asac> hmm ... not in the .pot at all for me
[12:45] <asac> but that the key might be duplicate anyway
[12:45] <jtv> I see no entities defined in brand.dtd.
[12:45] <jtv> Well, except that initial one.
[12:46] <jtv> I'm no XML guru but that doesn't look like a translatable string to me.
[12:46] <asac> <!ENTITY % realBrandDTD SYSTEM "chrome://branding/locale/brand.dtd">
[12:46] <asac> %realBrandDTD;
[12:47] <jetsaredim> asac: re:extensions - sorry, my system's been out of whack ever since I reinstalled with Hardy a couple weekends ago
[12:47] <asac> jetsaredim: ?
[12:47] <jetsaredim> but yea - the two I've done so far are fine
[12:47] <asac> jtv: ok lets not care for the brand.dtd for now
[12:48] <jtv> asac: then the problem we have is duplications.
[12:48] <asac> jtv: i think the main issue we have here is that we don't remember if there exist duplicate entries for a single key
[12:48] <jtv> We could, by setting the files as contexts.  Question is, is that the behaviour we want?
[12:48] <jtv> Or are they alternative translations for the same string?
[12:48] <asac> jtv: setting the files as context would be a workaround that might be feasible
[12:49] <asac> jtv: point is that for instance platformKeys.properties is really platform dependent
[12:49] <asac> jtv: can we add a hack for that ? ... e.g. prefer unix/ paths?
[12:49] <jtv> Ugly
[12:50] <jtv> Both code-wise and design-wise.
[12:50] <asac> yes.
[12:50] <jtv> Right now I think mac is going to be the default, simply because it comes first in an alphabetical traversal.
[12:51] <asac> jtv: yes. maybe we can prune directories called 'win' and 'mac' for now?
[12:51] <jtv> temporarily rename unix to 00-unix?
[12:51] <asac> hmm thats most likely as hacky :)
[12:52] <asac> jtv: i think not descending into mac and win directories should not regress any valid corner case for the packages we current care most about
[12:52] <asac> jtv: once we can parse the manifest we should include parts of the path into the key id
[12:52] <asac> e.g. key= global-platform/unix/intl.properties
[12:52] <asac> sorry
[12:52] <asac> e.g. key= global-platform/unix/intl.properties#SOMEKEY
[12:53] <jtv> Well, remember, that means you're translating a different string!
[12:53] <asac> but we cannot do that before we can parse the manifest
[12:53] <asac> jtv: huh?
[12:53] <asac> jtv: why do we translate a different string if we don't descent in "mac" and "win" directories during import?
[12:54] <jtv> I may be misunderstanding you.  If you insert the platform name in the message id, you're creating a different message.
[12:54] <asac> jtv: well ... in future we should include the chrome path for all ids
[12:54] <asac> otherwise its not guaranteed to be unique anyway
[12:54] <asac> (its just luck if there are no clashes)
[12:54] <asac> e.g. chrome://branding/locale/brand.dtd can have a key "key1"
[12:55] <asac> and chrome://branding/locale/brand2.dtd can have a key "key1" as well
[12:55] <asac> but both can refer to different strings
[12:55] <jtv> Right, we support adding context to the identification of a message, but once you do that, there is no relationship whatsoever between that message and another one with the same identifier in a different context.
[12:55] <asac> so in hardy+1 the chrome url path should be included in the key
[12:55] <asac> jtv: yes. thats what we want
[12:56] <jtv> But not for the platforms, right?
[12:56] <jtv> I mean, those are always the same strings but with different "en-US translations," right?
[12:56] <asac> jtv: no. they are differnt. thats why there are three directories
[12:57] <jtv> Ah ok.
[12:57] <asac> but we cannot include the complete path ... just the path that would be in the chrome:// url
[12:57] <jtv> In that case, yes, we should use file path as context.
[12:57] <asac> thats why we cannot do it right before we parse the manifest
[12:57] <asac> jtv: but i think its not a problem except for the platform cases here
[12:57] <asac> which we can now workaround by not descending into "win" and "mac"
[12:58] <asac> ... the xulrunnre en-US.xpi should be the most complex we have for hardy
[12:58] <asac> jtv: let me think
[12:58] <asac> jtv: maybe we can use the path after the |last| LANGCODE folder
[12:59] <asac> jtv: yes that should work
[12:59] <asac> jtv: no idea what is easier for you
[12:59] <asac> either don't descent into win or mac ... or include more context in the key
[12:59] <asac> the latter is of course cleaner
[12:59] <asac> and i most translation use that pattern i guess
[13:00] <asac> (most == all the we need for hardy)
[13:00] <jtv> Of course it does mean losing translations when a file is moved inside the XPI/JAR files.
[13:00] <asac> jtv: well, but the msgid would still trigger suggestions
[13:00] <asac> right?
[13:00] <jtv> YEs
[13:00] <asac> i don't think that its a problem
[13:01] <asac> we get most translations from upstream .xpi anyway
[13:01] <asac> and they only move such files on major version upgrades
[13:01] <asac> e.g. firefox 3 -> firefox 4
[13:01] <jtv> I'm thinking about how to skip mac/win directories.  Doing that in the import code will take time.  Is there no stage where you get to see the contents of the jar files as regular directory trees?  It'd be a few lines of shell script to hack it up at that stage.
[13:02] <asac> jtv: atm we don't introspect the .jar files
[13:02] <asac> during export
[13:03] <asac> jtv: doesn't the importer run over an extracted tree?
[13:03] <jtv> No
[13:03] <jtv> It iterates over files inside the zip files directly.
[13:03] <asac> strange. how does it get the ontent?
[13:03] <jtv> There's a python API for that.
[13:04] <jtv> Similar to iterating over the contents of a tarfile.
[13:04] <asac> ok. can't you just test if there is a "/win/" in or "/mac" in?
[13:04] <jtv> Yes, that part is easy.
[13:05] <asac> jtv: ok... what is left?
[13:05] <jtv> The problem is getting the change into the code soon.
[13:05] <asac> jtv: ok. thought the cherry-pick was not yet done
[13:05] <asac> or is that about the exporter?
[13:06] <jtv> That covers importer and exporter points, IIRC.  But this would have to be a separate effort.
[13:07] <jtv> Let me just see what happens to contexts right now.
[13:09] <jetsaredim> does the mozillateam troubleshoot all mozilla-related issues?
[13:10] <asac> jetsaredim: well. why do you ask?
[13:10] <asac> we are certainly a good point to start for everything mozilla related
[13:11] <jetsaredim> installed the acroread plugin from medibuntu and the mozilla-mplayer and don't see them in about:plugins
[13:11] <asac> jetsaredim: acroread plugin should be fixed by medibuntu
[13:11] <asac> mozilla-mplayer needs to be linked to the right directory
[13:11] <jetsaredim> asac: hence the reason I asked ;)
[13:11] <asac> thats on my list ... if you want to prepare a fix i would be happy to upload it right away
[13:11] <asac> jetsaredim: if its not in ubuntu we usually cannot deal with it by definition
[13:12] <asac> jetsaredim: if a medibuntu guy joins this channel this might chance of course :)
[13:12] <jetsaredim> heh
[13:12] <asac> but i don't know anyone from that effort
[13:12] <jetsaredim> so, what's the fix?
[13:12] <jetsaredim> for mplayer
[13:12]  * jetsaredim is not sure where the links should go
[13:12] <asac> jetsaredim: link the plugin to /usr/lib/xulrunner-addons/plugins/
[13:12] <jetsaredim> ahhh
[13:13] <asac> most likely its only liked to /usr/lib/firefix/plugins atm
[13:13] <asac> jetsaredim: create a debdiff and attach it to a bug ... i will instantly upload that :)
[13:13] <jetsaredim> yea - all of the /usr/lib mozilla/firefox etc
[13:13] <asac> jetsaredim: yep.
[13:13] <asac> jetsaredim: there are other plugins in universe as well i guess
[13:13] <jetsaredim> lemmie have a look
[13:14] <asac> cool :)
[13:14] <fta2> asac, i'm troubleshooting my ff3 crash. I've rebuilt ff3 and xul with --enable-debugger-info-modules (as asked by timeless) and with --enable-debug.. no real change: http://paste.ubuntu.com/5771/ any clue ?
[13:15]  * jetsaredim needs to re-build the dev environment
[13:15] <asac> fta2: yes. that happens because the symbols get stripped
[13:15] <asac> fta2: you should try to run it from dist/bin
[13:15] <fta2> are they ? when
[13:15] <asac> fta2: can you reproduce it from there?
[13:16] <asac> fta2: they are stripped by dh_strip ... which gets automatically run by cdbs
[13:16] <asac> you can pass the nostrip option as DEB_BUILD_OPTIONS
[13:16] <asac> or something like that
[13:17] <asac> fta2: yes. DEB_BUILD_OPTIONS=nostrip should help
[13:17] <fta2> no need to rebuild then ? just -nc ?
[13:18] <asac> fta2: if it works then yes
[13:18] <asac> fta2: but loooking at cdbs rules i am not really sure if it works
[13:19] <asac> maybe you need to specify the package not to strip in DEB_STRIP_EXCLUDE
[13:19] <fta2> it's the same with dist/bin
[13:20] <asac> fta2: yes. most likely because its in xul code (which when taken from package is of course still stripped)
[13:20] <asac> fta2: maybe you can reproduce with a plain firefox build?
[13:20] <asac> (e.g. without system-xul)
[13:21] <fta2> damn, i'll try to figure out a way to make it simpler for us
[13:21] <asac> that would be easiest to produce a backtrace from a not-striped build (e.g. just run in dist/bi)
[13:21] <asac> fta2: yes, try DEB_STRIP_EXCLUDE=packagename
[13:21] <asac> thats what i see in cdbs
[13:21] <asac> otherwise you need to read in cdbs and if there is no real option to disable stripping we need to fix cdbs
[13:22] <asac> (e.g. first ship our custom one in debian/cdbs)
[13:22] <asac> these are the points where cdbs can get a bit cumbersome ... plain debhelper would be easier to fix. but lets hope ... maybe just nostrip is enough ... or DEB_STRIP_EXCLUDE helps
[13:23] <jtv> asac: I think adding context looks doable, though as I said it'll take time.  If you've got more time in a minute, could you explain some XPI mechanics to me?
[13:23] <asac> jtv: sure ... what do you want to know
[13:24] <jetsaredim> asac: so, just to be sure - I'm just changing the mozilla-mplayer.links file right?
[13:24] <asac> jetsaredim: i think so yes. on what does mplayer build-depend
[13:24] <asac> ?
[13:24] <asac> firefox or libxul-dev?
[13:24] <asac> or none?
[13:25] <jetsaredim> debhelper (>= 4.1.0), cdbs, libx11-dev, libxpm-dev, libxt-dev, libxul-dev, libxext-dev, pkg-config, libgtk2.0-dev
[13:25] <jetsaredim> i don't think that has any bearing
[13:25] <asac> fta2: you can also see if installing the create-dbgsym package is enough
[13:25] <asac> jetsaredim: ok it still builds against xulrunner 1.
[13:25] <asac> 8
[13:25] <asac> but we don't need to fix that now (if it works properly of course
[13:25] <asac> )
[13:26] <asac> jetsaredim: try to add the proper link in .links (if thats the place where the other links are already added)
[13:26] <jtv> asac: hope I'm phrasing this right...  How can it be that e.g. the Mac and Unix versions of a string do have the exact same key?  Is that something that can validly happen anywhere else?
[13:26] <jetsaredim> asac: yep
[13:26] <asac> jtv: yes. thats what i said. without the context there is no guarantees for uniqueness
[13:26] <asac> jtv: mozilla code doesn't just say "give me translation for xyz-key"
[13:27] <asac> jtv: it always loads the translation file through a chrome path:
[13:27] <asac> chrome://platform/win/example.properties
[13:27] <asac> so you can have key1 in there
[13:27] <asac> and in another place you can have key1 in chrome://something/completely/different.properties
[13:28] <asac> jtv: that should be rare though because you run into issues if you want to use both in the same context
[13:28] <jtv> asac: so in XPI it's really the combination of chrome path and message key that identify a translatable string
[13:28] <asac> so most likely we just see that for platform stuff ... which is mutually exclusively included by using ifdefs
[13:28] <asac> jtv: right
[13:28] <jtv> How is the chrome path constructed?  Same for properties file and dtd file?
[13:28] <asac> jtv: for now using the path _after_ the last en-US folder in the path should be ok
[13:29] <asac> jtv: yes. to get the real chrome path you need to understand the chrome manifest
[13:30] <jtv> asac: When we import a translation, we'd have to strip other language codes similarly.  That's getting a bit scary.
[13:30] <jtv> asac: imagine you had a directory called "it" where "it" wasn't a language code, for example
[13:31] <asac> jtv: yes. thats why i mean that just skipping win/mac might be better as workaround
[13:31] <asac> jtv: we should fix it for real once we parse the chrome.manifest and understand how to guess the chrome path from it
[13:31] <fta2> asac, of course, i have all the dbgsym installed, otherwise nothing gets resolved, of course. I'm not sure I'll get more than what I already have provided in the bug
[13:31] <asac> jtv: yes. thats right
[13:32] <asac> fta2: try to install the -dbg packages for all depends
[13:32] <asac> e.g. libc, glibc, gtk
[13:33] <jtv> asac: one ugly but effective thing I think I could do is change the sorting order for zip-file traversal.
[13:34] <asac> jtv: thats ok as well. however we currently have mac + win properties ... so not sure if really depends on the sequence ... and not on soe other hask key randomness
[13:34] <asac> (i would have expected that we have either win ... or mac)
[13:35] <jtv> asac: I believe this is something Carlos added to his branch exactly because sort order was non-deterministic (though treacherously consistent on any given system)
[13:35] <jtv> asac: it used to be unsorted from what I understand, and is sorted now.
[13:36] <asac> jtv: ok. however the export shows both (which looks like his import was still random)
[13:37] <jtv> asac: that fix is not in production yet.  Let me verify that the sorting call is indeed recent.
[13:37] <asac> jtv: i think carlos used his test system to export
[13:37] <asac> jtv: otherwise there should have been more bugs we saw in the beginning
[13:38] <jtv> asac: is that where you got the template you showed me?
[13:38] <asac> jtv: yes. thats all what carlos gave me. i gave him the .xpi
[13:38] <asac> he exported it
[13:38] <jtv> ah, of course, it has to have his fixes because it has "!/" as jar path separators.
[13:38] <jtv> Those separators are something he added at your request.
[13:39] <asac> right
[13:39] <jtv> Then yes, this does look like it's caused by reordering somewhere further down the line.  :(
[13:40] <asac> jtv: is it really easier to change sort order compared to filtering out paths that include "/mac/" and "/win/ ?
[13:41] <jtv> asac: not easier, I was just trying to think of something less destructive.
[13:42] <jtv> asac: but as you say, this leaves skipping win/ and mac/ directories as the easiest alternative by far.
[13:42] <asac> jtv: right. if that is doable we should go for that
[13:45] <jtv> asac: it'll take a few days to get the change in.
[13:45] <asac> jtv: thats ok ... we can continue without them for now
[13:45] <asac> jtv: just wanted to tell you asap
[13:46] <jtv> asac: ok, I'll file a bug and try to get it done this week.
[13:47] <asac> jtv: great
[13:49] <jtv> asac: do you have a way of making sure we don't miss anything essential when we make do with this workaround?
[13:49] <asac> jtv: what do you mean?
[13:50] <asac> jtv: we can also add a file in the en-US.xpi: translate-blacklist.txt
[13:50] <jtv> asac: can we know that there are no other important message key clashes that we're not addressing this way?
[13:50] <asac> that would contain lines with reg expressions:
[13:51] <asac> .*platform.*win.*
[13:51] <asac> .*platform.*max.*
[13:51] <jtv> Blacklist is nice, but takes longer.  Not ideal for a workaround!
[13:51] <asac> jtv: we cannot know. we can only hope for now. we could see if there are clashes for xulrunner.pot and firefox.pot ... those should cover most cases
[13:52] <jetsaredim> asac: is there a bug for these mplayerplug-in changes?
[13:52] <jtv> asac: here's hoping the problem is not more widespread...
[13:52] <asac> jtv: yes. as i said. key clashes should be pretty rare within a single package
[13:53] <asac> because you could not use them in the same xul file. platforms are obviously something that are mutually exclusive so i suspect that we only see key clashes there
[13:54] <asac> jtv: same package => carlos said that it won't be a problem if there are the same keys in lets say firefox and an extension because the package already spans a context
[13:55] <asac> jtv: can't the importer log some warning or something if it detects a key clash? so we know at least?
[13:55] <asac> jetsaredim: look at the bugs in launchpad
[13:55] <jtv> asac: it probably does.  In fact I'm surprised we don't see multiple file names in the file references for such strings.
[13:55] <asac> jetsaredim: if there is none open a new one
[13:56] <asac> jtv: hmm. maybe thats a bug? or a missing feature?
[13:57] <jtv> asac: maybe.  It screws with your mind to think of a template import as a translation import etc.
[13:57] <asac> yeah
[13:57] <asac> bug 202468
[13:57] <ubotu> Launchpad bug 202468 in ubuntu "FFe: update swfdec-* to 0.6" [Undecided,New] https://launchpad.net/bugs/202468
[14:01] <jtv> asac: yup, the XPI import code logs it.  Just a matter of running at a high verbosity level.
[14:01] <asac> ok
[14:01] <asac> jtv: do you have a local test system where we could import the en-US.xpi to see if there are other clashes?
[14:03] <fta2> asac, my ff3 was both with --enable-debug and later --disable-debug :(
[14:03] <jtv> asac: for a fairly wild definition of "local," yes.  :)
[14:03] <fta2> asac, with just --enable-debug, it ftbfs
[14:04] <fta2> asac, http://paste.ubuntu.com/5773/
[14:05] <asac> fta2: yes. most likely a bug in how system-xul is used
[14:06] <asac> fta2: maybe try to just build browser in a pristine upstream tree ... or do you already know that it doesn't crash in that case?
[14:06] <fta2> i don't
[14:06] <asac> jtv: well. i mean "local" like in "we can change code and test things" :)
[14:07] <fta2> asac, i need to fetch a complete tarball for that so i just wanted to use our packages
[14:07] <asac> fta2: give it a try then. most easiest way to figure things. i guess that the above error happens because xulrunner isn't build with --enable-debug
[14:07] <jtv> asac: oh, here's a completely different approach: instead of logging "message already exists," maybe we can overwrite the existing file location we associate with the message, if and only if the new file location replaces a "/mac/" or a "/win/" with a "/unix/".
[14:07] <asac> fta2: yes, but you definitly cannot build firefox with enable-debug if xulrunner isn't
[14:08] <fta2> xul is
[14:08] <asac> fta2: so are there _all_ components/ ?
[14:08] <asac> installed?
[14:08] <asac> e.g. is there xpcom_core?
[14:08] <jtv> asac: in other words, do what we do now, but make a "unix" file location override a "mac" or "win" one.
[14:08] <jtv> asac: and do the same for the "English translation," of course.
[14:08] <asac> jtv: yes, that would add more safety belts i guess
[14:09] <asac> in case there is a directory name win that isn't platform specific
[14:10] <fta2> xul has libxpcom_core.a, probably bundled into libxpcom.so
[14:10] <jtv> asac: right, the easiest way is probably just to count instances of each of the names and see which version of the message has a "better" pedigree.
[14:11] <asac> fta2: yes, but iirc in debug builds there should be a libxpcom_core.so (might be wrong though)
[14:12] <asac> fta2: we had that when developing midbrowser: debug builds don't link everything in a libxul.so ... but keep the components as .so files individually
[14:13] <asac> fta2: does the xulrunner package ship that libxpcom_core.a file?
[14:17] <jtv> asac: https://bugs.edge.launchpad.net/rosetta/+bug/203172
[14:17] <ubotu> Launchpad bug 203172 in rosetta "Clashing platform-specific msgids in XPI" [Undecided,New]
[14:17] <jtv> You'll see yet another suggestion at the end.
[14:18] <asac> fta2: anyway. i really don't think its easily doable to have a splitted debug build.
[14:18] <asac> fta2: most likely there are a bunch of issues here
[14:20] <asac> jtv: ok. i think the second solution is the most fail safe one we currently have
[14:20] <asac> the third might also cause confusion if there are folders "win" ... i guess
[14:20] <asac> or ?
[14:20] <jtv> asac: well, I was thinking of appending *any* instances of each of those.
[14:20] <jtv> asac: so say you have directories "lose" and "win"
[14:21] <jtv> asac: and then inside "win" you have win/mac, win/win, and win/unix,
[14:21] <asac> hmm
[14:21] <jtv> asac: then you'd get contexts like "win/mac" and "win/unix" and "win/win"
[14:21] <asac> jtv: yes. however that might be a conversion problem later once we can parse the manifest
[14:22] <asac> e.g. introducing hacked contexts. but i guess you can better judge on that
[14:22] <jtv> asac: well we'd have to re-import those messages anyway, I think...
[14:22] <asac> right
[14:22] <asac> jtv: point is we also have to guess the path to use when constructing an .xpi from the .po
[14:22] <asac> not sure how easily that can be done with those exceptions
[14:23] <jtv> asac: but you do that based on the file references, not on the context, right?
[14:23] <asac> how would the comment read for such a win/mac thing?
[14:23] <asac> jtv: yes. i am a bit unsure what the context and what the file reference is i guess
[14:23] <jtv> asac: unchanged, but the messages would have an extra directive,
[14:23] <jtv> msgctxt: win/mac
[14:23] <asac> ah
[14:23] <jtv> (Ahem, with quoting)
[14:24] <asac> ok so the po2xpi transformer can just ignore that right?
[14:24] <jtv> asac: it's a bit confusing given how we use them here, but file reference is the comment field with the foo.xpi/dir/bar.jar!/here/is/my/file.dtd in it
[14:24] <jtv> asac: whereas the context is specified by an extra directive that you don't see yet.
[14:25] <jtv> asac: po2xpi ignores the context already, because it's not there.  :-)
[14:25] <asac> jtv: ok. from what i understand it would be ok as it most likely would remove the clashes from the ones we currently see without changing the approach for constructing the xpi from po
[14:25] <jtv> You'd just need to teach your parser to ignore msgctxt directives, I think.
[14:25] <asac> so i am fine with option 2 and 3
[14:25] <jtv> And teach it not to expect keys to be unique within the entire PO file you get, of course.
[14:26] <asac> so if you feel better to hack it in that way, using the msgctxt would be fine
[14:29] <jtv> asac: I'll end up playing with the possibilities a bit anyway, but I think this one minimizes the inconvenience to users of other platforms.
[14:29] <jtv> asac: They have it hard enough as it is.  :-P
[14:30] <asac> jtv: hehe ... well, personally i don't mind to ignore other platforms for this first step
[14:30] <asac> so you can decide
[14:30] <asac> :)
[14:33] <jetsaredim> asac: I can't seem to push this new mplayerplug-in up my bzr area
[14:34] <asac> jetsaredim: is it a bzr branch at all?
[14:34] <asac> what happens?
[14:34] <jetsaredim> i made a new one
[14:34] <jetsaredim> bzr init, bzr add .
[14:34] <jetsaredim> bzr push bzr+ssh://jetsaredim@bazaar.launchpad.net/~jetsaredim/mplayerplug-in
[14:34] <jetsaredim> bzr: ERROR: Generic bzr smart protocol error: Permission denied: "This method is only for creating branches: /~jetsaredim/mplayerplug-in"
[14:40] <asac> jetsaredim: is there any mplayerplugin-in project at all?
[14:40] <asac> further you need to create a branch
[14:40] <asac> e.g. try
[14:40] <asac> bzr push bzr+ssh://jetsaredim@bazaar.launchpad.net/~jetsaredim/mplayerplug-in
[14:40] <asac> bzr push bzr+ssh://jetsaredim@bazaar.launchpad.net/~jetsaredim/mplayerplug-in/ubuntu
[14:41] <asac> e.g. the second path element is just the project ... so you lack the ubuntu to not get the "only for creating branches" error
[14:42] <jetsaredim> yea - got it
[14:42] <asac> great
[14:42] <jetsaredim> https://code.edge.launchpad.net/~jetsaredim/mplayerplug-in/193812
[14:42] <jetsaredim> (bug number)
[14:43] <jetsaredim> gotta install it, but I'm faily certain it will work
[14:43] <asac> bug 193812
[14:43] <ubotu> Launchpad bug 193812 in mplayerplug-in "mozilla-mplayer plugin isn't detected in Firefox 3.0beta3" [Undecided,Confirmed] https://launchpad.net/bugs/193812
[14:43] <asac> jetsaredim: once you have done that please add the debdiff to the bug
[14:43] <asac> and let me know
[14:43] <asac> (done that ==  tested)
[14:44] <jetsaredim> yep - want to build it in my ppa
[14:57] <jetsaredim> asac: how do I build mozilla-mplayer?  When I did the debuild it only builds mplayerplug-in...
[14:58] <asac> jetsaredim: most likely its the wrong package htne
[14:58] <asac> apt-get source mozilla-mplayer should give you the right sources
[14:59] <jetsaredim> yea - that's what I did
[15:03] <jetsaredim> the control file says package: mozilla-mplayer source:mplayerplug-in
[15:04] <asac> jetsaredim: debuild -b should build it then
[15:04] <jetsaredim> i did both debuild -b and debuild -S -sa and I only have mplayerplug-in files
[15:05] <jetsaredim> changes, deb etc all mplayerplug-in
[15:19] <fta2> asac, john is back ?
[15:19] <fta2> I see he's doing some bug work
[15:32] <asac> fta2: cool
[15:32] <asac> fta2: his mail said he will be in hospital till end up apr
[15:54]  * jetsaredim pulls hair out
[16:04] <fta2> asac, network manager has been pushed in hardy with debug enabled ???
[16:06] <fta2> bug 198531
[16:06] <ubotu> Launchpad bug 198531 in nautilus "Connecting to SSH or Samba server gives "The specified location is not mounted" error" [Medium,Fix released] https://launchpad.net/bugs/198531
[16:18] <asac> fta2: why do you think it is with debug?
[16:19] <CheGuevara> asac, are you still gonna update your 0.7 packages?
[16:19] <asac> CheGuevara: yes. i will do that once i have everything else done :)
[16:19] <asac> ... its not a high priority
[16:19] <asac> CheGuevara: updating based on my bzr branches should be easy enough though
[16:20] <CheGuevara> am too scared to use it now
[16:20] <CheGuevara> last time, it half updated and n-m restarted before somethign else installed
[16:20] <CheGuevara> so the rest couldn't download and install
[16:20] <CheGuevara> ended up with a b0rked system lol
[16:26] <asac> strange ... usually things get downloaded _before_ they get installed
[16:27] <asac> i think in the beginning there were some too lax dependency which might not have auto updated your applet. that should be resolved by now
[16:51] <fta2> asac, because my logs are filled with messages such as NetworkManager: <debug> [1205768279.068140] nm_hal_device_removed(): Device removed (hal udi is '/org/freedesktop/Hal/devices/volume_uuid_98AB_B3D0').
[16:52] <fta2> (when i plug my usb key)
[16:53] <asac> fta2: yes, but that was always that way afaik
[16:54] <fta2> i don't remember it
[16:54] <fta2> unless somthing changed my logckeck rules
[16:55] <asac> fta2: you didn't use nm at all afaik :)
[16:55] <fta2> true but it's installed
[16:56] <asac> yeah ... it was always that way, for sure. maybe its just that udev became more eventish
[17:21] <fta2> asac, http://blog.vlad1.com/2008/03/16/cairo-16-quartz-and-gecko/
[17:21] <koke_22> hola
[17:23] <koke_22> alguien me puede ayudar????
[17:32] <jetsaredim> asac: ok - tried out the new mozilla-mplayer and it seems fine
[17:33] <jetsaredim> what is the debdiff - the diff.gz file?
[17:38] <jetsaredim> asac: updated 193812
[17:38] <jetsaredim> err bug 193812
[17:38] <ubotu> Launchpad bug 193812 in mplayerplug-in "mozilla-mplayer plugin isn't detected in Firefox 3.0beta3" [Undecided,In progress] https://launchpad.net/bugs/193812
[17:38] <jetsaredim> i attached my debdiff, added my branch, and assigned it to you
[17:38] <jetsaredim> :)
[18:07] <asac> ok back
[18:07] <asac> was on a cal
[18:07] <asac> fta: you have a cloak now ... great!
[18:08] <asac> jetsaredim: the debdiff is produced by debdiff *.dsc
[18:08] <jetsaredim> o hmm
[18:08] <asac> e.g. first argument = original dsc
[18:08] <jetsaredim> so what i uploaded to the bug is not it?
[18:08] <asac> second argumnet = new dsc
[18:08] <asac> if you didn't use debdiff then most likely its not .)
[18:09] <jetsaredim> i just cd to the local branch and did debdiff
[18:09] <jetsaredim> came back with a normal-looking diff file
[18:09] <asac> looks like a valid debdiff
[18:09] <jetsaredim> so i assume that was it
[18:09] <asac> (however you created it)
[18:09] <jetsaredim> ok then :)
[18:12] <asac> jetsaredim: at some point you might want to work on migrating the build-depend from libxul-dev to xulrunner-1.9-dev ...
[18:12] <asac> but is good enough for now
[18:12] <asac> just keep it on your list of "more" sophisticated things to do in case you are looking for a challenge
[18:14] <asac> jetsaredim: oh ... you should remember to close the bug in changelog (so archive admins can easily see the review/discussion)
[18:14] <asac> jetsaredim: look at how the changelog reads that i upload to get an idea on the syntax
[18:16] <asac> jetsaredim: ok uploaded
[18:19] <asac> fta: do you have amd64 at hand?
[18:21] <jetsaredim> asac: where to see the changelog?
[18:21] <asac> jetsaredim: in launchpad ... look at the package
[18:21] <asac> there is a list of every upload done
[18:22] <asac> https://edge.launchpad.net/ubuntu/+source/mplayerplug-in
[18:22] <asac> on the main page for the package
[18:22] <asac> ubuntu2 should appear there any time soon
[18:22] <asac> also the bug will now automatically receive a copy of the changelog because i closed it with this upload
[18:25] <asac> cwong1: vlad and roc are good contacts to start for asking about how to att fingerscroll support.
[18:25] <asac> (in case you didn't get their names)
[18:26] <asac> they should at least be able to bounce you to the right contacts
[18:29] <jetsaredim> asac: ok thanks :)
[18:44] <fta> back
[18:45] <asac> jetsaredim: takes a bit to get in. needs archive admin approval (as we are in beta)
[18:45] <asac> fta: are you on amd?
[18:46] <fta> at work, I have an amd but it's running i386 now
[18:46] <asac> hmm. ok
[18:48] <fta> why ??
[18:48] <asac> well  i need someone to test nspluginwrapper merge :)
[18:49] <asac> e.g. if it still works with flashplugin-nonfree
[18:49] <asac> the diff looks good, but my amd system is currently broken
[18:50] <asac> hmm ... why do i already have all these kde libs on my system
[18:50] <asac> even though its my new laptop :(
[18:50] <asac> pestilence
[18:51] <fta> lol
[18:51] <asac> i really would like a feature, like: remove all kde things when running apt-get autoremove
[18:51] <asac> so i can install them in case i need them to build something and then instantly wipe them
[18:51] <fta> $ dpkg -l | grep -c kde
[18:51] <fta> 0
[18:52] <asac> yeah ... i think it was gnash that brought this dirt on my disc
[18:52] <fta> i only build stuff in chroots
[18:52] <asac> (required to build klash)
[18:52] <fta> except my own projects
[18:52] <fta> but i don't do kde at all
[18:52] <asac> yeah, but this laptop just has 80G ... so i feel reluctant to setup chroots
[18:53] <fta> a chroot for packaging is usually small
[18:53] <asac> if you do it like for pbuilder
[18:54] <asac> otherwise it will grow and grow over time
[18:54] <asac> but using pbuilder just creates too much disc activity on a laptop imo
[18:54] <fta> 100M for the base, 1G with builddeps for a moz stuff, 1 more G for the moz stuff itself
[18:54] <fta> just clean you build-area weekly
[18:58] <fta> +r
[18:58] <fta> --enable-debugger-info-modules=yes doesn't help for my crash
[19:04] <asac> fta: do you have a plain upstream build-tree now?
[19:04] <fta> no, doing it right now
[19:06] <jetsaredim> asac: i guess it does take a while to get uploaded
[19:06] <jetsaredim> :)
[19:09] <asac_> sorry i was temporarily banned after recoonnect
[19:09] <asac_> had to get a new ip first
 fta: do you have a plain upstream build-tree now?
 no, doing it right now
 asac: i guess it does take a while to get uploaded
 :)
[19:11] <asac_> its already uploaded
[19:11] <asac_> just sitting in the queue requiring a punch
[19:12] <asac_> its in universe so it will just happen once an release team members visits the queue
[19:17]  * jetsaredim punch
[19:18] <asac_> jetsaredim: your punch is too weak to help here :-P
[19:19] <jetsaredim> need "hulk smash!"
[19:24] <jetsaredim> asac: can you explain more about your xulrunner comment?
[19:24] <asac> the idea is to built against xulrunner-1.9-dev
[19:25] <jetsaredim> vs xul-dev?
[19:25] <asac> libxul-dev is from xulrunner 1.8
[19:25] <asac> jetsaredim: https://wiki.ubuntu.com/XulrunnerGecko
[19:26] <asac> that is a basic introduction ... though the examples are a bit outdated ... and over complicated
[19:26] <asac> but in general it should still be the right line
[19:26] <asac> to pursue
[19:27] <asac> jetsaredim: look at the basics and thte totem example
[19:27] <asac> mplayer is probably different, but the direction should still be valid
[19:40] <asac> [reed]: http://tinyurl.com/26bwsw
[19:40] <asac> hmm
[19:41] <asac> [reed]: http://tinyurl.com/3ccfv6
[19:41] <asac> thats the one
[19:43] <asac> should i add checkin-needed everywhere or is it ok that way?
[19:46] <fta> epiphany-browser: jemalloc.c:4190: arena_dalloc: Assertion `arena != ((void *)0)' failed.
[19:46] <fta> Abort (core dumped)
[19:46] <fta> ohoh
[19:47] <asac> [reed]: ok CCed you on two more sec bugs appeared to not see
[19:47] <asac> [reed]: how many can you commit of those 26?
[19:47] <asac> fta: sounds bad
[19:47] <asac> fta: can you reproduce?
[19:48] <fta> prism is dead too
[19:48] <asac> (is that enabled in beta4 already?)
[19:48] <asac> ah ok. so just trunk rumbling
[19:48] <asac> or is that with your debug biuld-tre?
[19:54] <fta> xul and ff3 built as usual + --enable-debugger-info-modules=yes
[19:56] <fta> http://pastebin.ubuntu.com/5790/
[20:10] <asac> fta: so is it because of the modules?
[20:11] <asac> fta: did you manage to disable stripping?
[20:19] <fta> asac, i've added a firefox-3.0-full projet in mozclient
[20:23] <asac> fta: good. how can we get that?
[20:23] <asac> just include the .mk i guess :)
[20:23] <asac> does it still produce nobinonly?
[20:23] <fta> yes, or make -f /usr/..../firefox-3.0-full.mk get-orig-source
[20:23] <fta> yes
[20:23] <asac> great
[20:38] <fta> hm, prism works now. same debs
[20:38] <asac> well ... memory access issues can be random
[20:38] <asac> that doesn't mean that there isn't a problem
[20:39] <asac> can you run that in debugger
[20:39] <asac> ?
[20:39] <fta> the ff3 crash is 100% reproducible, same stack
[20:47] <asac> with upstream build-tree?
[20:48] <fta> no, our branches
[20:48] <fta> i'm building ff3-full with debug now.. takes a while
[20:48] <asac> did upstream built tree finished
[20:48] <asac> ok
[20:52] <fta> are you done with lp-locale-export ?
[20:52] <fta> and xpi ?
[21:01] <fta> make[2]: Entering directory `/src/bzr/build-area/firefox-3.0-full-3.0~b5~cvs20080316t0643+nobinonly/build-tree/mozilla/browser/installer'
[21:01] <fta> Makefile:70: *** you need a "--enable-static or --enable-libxul" build to package a build.  Stop.
[21:10] <fta> from dist/bin, it's ok, no crash
[21:10] <fta> which is expected as it crashes when comparing the xul gre versions
[21:27] <asac> fta: a typo?
[21:27] <saivann> asac : If you want to merge it, I published a branch for ubufox that use the beautiful icon for ubufox instead of the actual .ico file. https://bugs.edge.launchpad.net/ubuntu/+source/ubufox/+bug/176658
[21:27] <ubotu> Launchpad bug 176658 in ubufox "ubufox icon could be cleaner" [Wishlist,Triaged]
[21:28] <fta> asac, typo ?
[21:28] <asac> fta: whats in your gre.d?
[21:28] <asac> maybe its bogus?
[21:29] <fta> no, it's correct
[21:29] <asac> saivann: looking
[21:29] <saivann> asac : Just to give you the status : I got eu_ES, hu_HU, pl_PL and fi_FI translations for ubufox so far.
[21:29] <fta> and I have a real collection of those :)
[21:29] <asac> saivann: you rock
[21:30] <fta> 1.9a8pre.system.conf  1.9a9pre.system.conf  1.9b2pre.system.conf  1.9b3pre.system.conf  1.9b4pre.system.conf  1.9b5pre.system.conf  libxul0d.conf
[21:30] <fta> 1.9a8.system.conf     1.9b1.system.conf     1.9b2.system.conf     1.9b3.system.conf     1.9b4.system.conf     firefox.conf
[21:30] <asac> saivann: did you receive any acks for those from a 2nd peer on the translations list?
[21:30] <saivann> asac : Hehe thanks :) Don't do it right now if you don't have time, I'm often here
[21:31] <asac> saivann: its not required, but for those that arrive early, we might want to verify that they don't contain low-quality translations
[21:31] <saivann> asac : The translations come from people who answered to my call in the ubuntu translations list
[21:31] <asac> saivann: right. i am not sure how the localization team is structured, by aren't there any "senior" contacts we could ask to review them?
[21:31] <saivann> asac : It would be important, yes. If you have some ideas about that, I'm ready to work
[21:32] <asac> saivann: do the translation teams have a launchpad team each?
[21:32] <saivann> asac : I'm not really aware of this too.. I will look if there is a ubuntu-localisation channel or something like that
[21:32] <asac> saivann: if there are launchpad teams you could look for the administrator
[21:32] <asac> or something
[21:33] <saivann> asac : This would make sense, thanks for that suggestion, I will search in this direction
[21:33] <saivann> asac : My deadline is NonLanguagePackTranslationDeadline, that's right?
[21:35] <fta> asac, prism crashes on shutdown now.. inside cairo
[21:35] <saivann> asac : I must go for the next minutes but if you talk to me or send me a email, I wil get your message. Thanks
[21:36] <fta> asac, http://paste.ubuntu.com/5797/
[21:39] <asac> saivann: if possible ahead of that. we might be able to inject those as initial translations to launchpad with a bit of luck"
[21:40] <asac> saivann: but not before my export code can properly strip the jar files to only contain files related to a certain language
[21:40] <asac> that won't happen before beta at least
[21:41] <asac> fta: maybe repeat what kind of thing that is? what versions are you running?
[21:41] <asac> fta: will it stop to crash if you build without system-cairo?
[21:41] <fta> cvs20080316t0643
[21:42] <fta> the crash is an assert because something is leaked
[21:42] <asac> looks like its a resurrection of live-entries assertion bail-out --- which is why we stopped using system-cairo back at a5 or something
[21:42] <fta> i guess it's fatal only in the debug build
[21:42] <asac> fta: yes, might be
[21:43] <asac> otoh its in cairo ... so why would a debug biuld of xulrunner using system cairo change a thing?
[21:43] <asac> fta: didn't you start this whole debugging because you had a crash in non-debug builds?
[21:43] <fta> yes
[21:43] <fta> crash in ff3
[21:44] <fta> at startup, not shutdown
[21:44] <asac> so it _does_ happen in non-debug builds
[21:44] <fta> yes
[21:44] <fta> ff3 yes
[21:44] <fta> prism, i don't remember
[21:44] <asac> yes. we had startup as well ... though shutdown was the line we usually settled on back
[21:44] <asac> fta: figure the checkin that caused this in bonsai :)
[21:45] <fta> my ff3 crash has nothing to do with cairo
[21:45] <asac> when did it start?
[21:45] <asac> whed was the last build working wll?
[21:45] <asac> fta: you sure?
[21:45] <fta> 20080316 0643 NOK
[21:45] <fta> 20080314 1505 OK
[21:45] <asac> what timezone are those?
[21:45] <fta> moz
[21:45] <asac> the right one for bonsai?
[21:45] <asac> ok
[21:46] <fta> mozclient dates
[21:46] <asac> does mozclient transform them?
[21:46] <fta> no, bonsai dates
[21:46] <fta> same
[21:47] <asac> bug 399694
[21:47] <asac> mozilla bug 399694
[21:47] <asac> hmm sec sensitive
[21:48] <asac> cairo upgrade landed
[21:48] <asac> maybe thats the problem?
[21:49] <asac> mozilla bug 421422
[21:49] <ubotu> Mozilla bug 421422 in GFX: Thebes "Upgrade cairo to 1.5.12-56-ga33351f" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=421422
[21:49] <asac> so git head ga33351f
[21:50] <asac> mozilla bug 404123
[21:50] <ubotu> Mozilla bug 404123 in Layout: Form Controls "[FIX]Percentage padding on <legend> triggers "ASSERTION: Bogus availSize.width.  Should be bigger"" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=404123
[21:50] <asac> mozilla bug 354502
[21:50] <ubotu> Mozilla bug 354502 in Layout "Legend tag does not wrap when specified" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=354502
[21:51] <asac> those touch layout as well
[21:51] <asac> another gfx: mozilla bug 418105
[21:51] <asac> lets assume that it really changes mac only
[21:51] <ubotu> Mozilla bug 418105 in GFX: Mac "Remove non-cairo Mac gfx code from the tree" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=418105
[21:52] <asac> the others look unrelated
[21:52] <asac> aka unlikely to cause that imo
[21:53] <asac> the initial crash is in jemalloc?
[21:53] <asac> maybe browser builds its own copy of jemalloc?
[21:53] <asac> fta: ?
[21:54] <asac> Bug 418016 Follow-up patch: force static jemalloc lib, to fix bustage for non-libxul linux builds. r+sr=pavlov a=blocking1.9+
[21:54] <asac> mozilla bug 418016
[21:54] <ubotu> Mozilla bug 418016 in XPCOM "Ts jumped ~1% when enabling jemalloc on Linux (qm-mini-ubuntu01, qm-mini-ubuntu02, qm-mini-ubuntu05)" [Minor,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=418016
[21:54] <fta> this is my crash: mozilla bug 423334
[21:54] <ubotu> Mozilla bug 423334 in General "crash at startup in NS_CompareVersions" [Critical,New] http://bugzilla.mozilla.org/show_bug.cgi?id=423334
[21:59] <fta> building 20080315t1200 to cut the tree in half
[21:59] <asac> fta: i'd go for one of the jemalloc commits
[22:00] <asac> if it really crashes that early its unlikely that its a crash in some gfx/layout code
[22:00] <asac> there are just three commits in that timespan
[22:00] <fta> too bad we don't have hourly debs :(
[22:00] <asac> fta: did you respin firefox?
[22:02] <fta> ?
[22:05] <fta> i have my script to do all that: ./update-pkg.sh -d 20080315t1200 xulrunner-1.9.head firefox-3.0.head ; ./sync-ppa.pl ; ./build-ppa.pl
[22:06] <fta> the 1st pull the tarballs and update the branches, the 2nd merge the branches into my ppa branches, the 3rd builds the ppa branches and install the result in my chroot
[22:07] <fta> it will just skip the dput :)
[22:12] <asac> fta: are .debs for superseeded builds still available in launchpad?
[22:13] <fta> not sure. I've pushed the broken debs a bit too fast so I asked lp to delete them, but nothing else remained, ie the superseded ones were supposed to stay 24h but I couldn't find them
[22:14] <asac> so they get removed from launchpad?
[22:14] <asac> thats unfortunate
[22:15] <asac> ill think about the situation
[22:17] <asac> is far from perfect right now. i need a tinderbox, i need a daily ppa, i need a pfs server :-D
[22:17] <asac> daily ppa with archiving :)
[22:19] <fta> i have all the software to do that, i just need the hardware
[22:20] <asac> bug 176658
[22:20] <ubotu> Launchpad bug 176658 in ubufox "ubufox icon could be cleaner" [Wishlist,Triaged] https://launchpad.net/bugs/176658
[22:20] <fta> oh, vlad assigned himself on the red line in greader
[22:20] <fta> and it's blocking1.9+
[22:20] <fta> + ?
[22:21] <fta> oh, approved blocking1.9 ?
[22:27] <asac> yes
[22:37] <fta> mozilla bug 421069
[22:37] <ubotu> Mozilla bug 421069 in Layout "specifying line-height in px or with decimal values causes rendering errors" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=421069
[22:56] <fta> asac, seems there are a log of lp bugs to push to mozilla
[22:56] <fta> lot
[23:03] <[reed]> asac: I can commit them all, it just might take me a while... committing takes time to make sure it's done correctly
[23:03] <[reed]> asac: give people a couple of days / a week or so, and then add checkin-needed
[23:04] <asac> k
[23:05] <[reed]> if it's bzbarsky
[23:06] <[reed]> just add checkin-needed
[23:06] <[reed]> he's already said that ;)