[04:08] <[reed]> ah, I'm feeling much better
[04:09] <[reed]> my flight has been fixed
[07:40] <jtv> asac: ping
=== asa2 is now known as asac__
[10:03] <asac__> fta: i can't reproduce the crash with a normal build tree using -libxul-sdk for whatever reason. will see if its because xul is build with debug
[10:05] <asac__> illl do another build with optimize and not debug
[10:08] <asac__> asac: are you really still here? you should be dead for some time now
[10:14] <DarkMageZ> asac__, it doesn't reply to version requests. just ghost it with nickserv
[10:15] <asac__> DarkMageZ: huh?
[10:15] <asac__> the point is that my gateway is dead right now
[10:15] <asac__> physically
[10:15] <asac__> but still this nick running on it is here :)
[10:16] <asac__> and the nick disappeared from other nets i am on a few minutes ago
[10:17] <DarkMageZ> freenode has a long timeout period.
[10:17] <asac__> ok lets wait a bit longer
[10:21] <asac__> byby
[10:21] <asac__> ok at least that works :)
[10:40] <asac__> fta: i cannot reproduce crash ... maybe its your nss/nspr things that break this?
[10:41] <asac__> ok trying to build package now to see if that makes a difference
[11:03] <asac> ok i am back in this thing
[11:04] <asac> lets hope my provider and power provider stay up for the next 10 hours or so
[11:04] <asac> (both went down)
[11:05] <asac__> logging this sidetrack out
[11:06] <asac> everything lost in irssi backlog ... if you asked soemthign in the last 12 hours repost
[11:27] <armin76> asac: <jtv> asac: ping <- at 07:01 GMT
[11:27] <armin76> 07:40, not 01 :P
[11:28] <asac> jtv: yes?
[11:32] <jtv> asac: hi
[11:32] <jtv> asac: I was just wondering about the clashing message keys we discussed
[11:32] <jtv> asac: right now afaics, if a key occurs in two files, you still see only one file listed.
[11:33] <jtv> asac: I could, in principle, change that so that messages with the same key and the same English text were shown once, with multiple occurrances.
[11:33] <jtv> asac: but that might screw up your parser.
[11:42] <asac> fta: what i find strange is that i could build latest cvs trunk checkout with current nss, but now can't when trying to build the xul 1.9 package from bzr
[11:43] <asac> jtv: hmm. why is it shown only once?
[11:43] <asac> jtv: i thought we add a msgctxt now
[11:43] <asac> so they should appear with same #: comment, but with different msgctxt
[11:43] <asac> or did i get that wrong?
[11:44] <asac> or do you mean for cases hat are not because of win/mac arch (which is a special case here)
[11:44] <asac> aeh ... hard to parse i guess
[11:44] <asac> :)
[11:44] <asac> what i said
[11:46] <asac> jtv: now i am a bit confused. what was the status quo of our discussion again?
[11:47] <asac> it was to add a special case for platforms, and include a msgctxt to differentiate those, right?
[11:47] <jtv> asac: right
[11:48] <jtv> asac: I didn't mean to confuse you...  For every message in the exported file, you get exactly one comment showing the file name that the message came from, right?
[11:48] <asac> yes
[11:48] <jtv> asac: (BTW I think I lost the link to that sample template you got from Carlos... where is it again?)
[11:49] <asac> jtv: i received it by mail
[11:49] <jtv> asac: Well, since we can have the same message in multiple files, I could in principle try to unify all versions of that message that have the same key and the same English text.
[11:50] <jtv> asac: in principle (though I'm not sure how far this would go in practice with current code) we could present the truly identical versions of the same message key as a single translatable string.  It'd save some effort.
[11:50] <jtv> asac: but for now I think I won't work on that.
[11:51] <jtv> asac: for now I'm concentrating on providing disambiguating context.
[11:53] <asac> jtv: ok. i don't think its required now
[11:53] <asac> jtv: lets keep things simple so we can get something at least
[11:53] <jtv> asac: that's what I'm doing.  :)
[11:54] <jtv> asac: the idea came up because I was still exploring what changes would be needed.
[12:02] <asac> jtv: well. in cases there is a id clash that is dealt with by contexting this would be useful
[12:03] <asac> but i hope its not required :)
[12:28]  * asac lunch time
[12:39] <fta2> asac, what ? how does it fail ?
[12:45] <armin76> asac: fta2: you aren't using hunspell :P
[12:45] <armin76> fix0r
[12:48] <fta2> eh ?
[12:48] <fta2> sure i am
[12:48] <fta2> i have  --enable-system-hunspell
[12:49] <fta2> and i'm using it
[12:49] <armin76> hrm...
[12:49] <armin76> on firefox you aren't
[12:50] <armin76> --enable-system-myspell \
[12:50] <fta2> it's not needed
[12:50] <fta2> fta@cube:~ $ lsof -p 10826 | grep huns
[12:50] <fta2> firefox 10826  fta  mem    REG        8,1   204416   541758 /usr/lib/libhunspell-1.1.so.0.0.0
[12:51] <armin76> then may want to remove that line :P
[12:51] <fta2> I don't have it
[12:51] <fta2> https://bugzilla.mozilla.org/show_bug.cgi?id=423334#c14
[12:51] <ubotu> Mozilla bug 423334 in XPCOM "crash at startup in [@ NS_CompareVersions] when using --with-libxul-sdk" [Critical,New]
[12:51] <armin76> http://bazaar.launchpad.net/~mozillateam/firefox/firefox-3.0.dev/annotate/asac%40jwsdot.com-20080313155724-p6ankuk4xiul1tcb?file_id=rules-20070321172126-hx4btlytc64jyo4n-23
[12:52] <fta2> that's firefox-3.0.dev, i'm talking about *.head
[12:53] <armin76> oh :)
[12:53] <armin76> http://bazaar.launchpad.net/~mozillateam/firefox/firefox-3.0.head/annotate/fta%40sofaraway.org-20080319215500-kpzjnzylg6z2th7m?file_id=rules-20070321172126-hx4btlytc64jyo4n-23
[12:53] <armin76> its still there :P
[12:53] <armin76> line 116
[12:54] <fta2> oh myspell
[12:54] <fta2> but anyway, i have no problem to build trunk or the .head branches
[12:55] <armin76> i know
[13:01] <fta2> asac, so what's your problem ?
[14:02] <asac> fta2: my problem is that xulrunner head doesn't build against current nss, while my trunk checkout does :)
[14:03] <asac> nevermind :)
[14:05] <asac> retrying
[14:47] <asac> fta2: ok with the leaking parser i don't see a crash
[14:51] <asac> fta2: i get the feeling that your system is special :)
[14:51] <asac> (which isn't bad in this case)
[15:00] <asac> fta2: how do you built your local packages?
[15:00] <asac> (you see the crash there as well, right?
[15:04] <asac> fta2: the interesting thing is that you build with symbolic-functions
[15:04] <asac> i don't do that and don't see any crash
[15:04] <asac> (at least with the leak)
[15:04] <asac> now i wonder how it happens that you pull in those default LDFLAGS
[15:04] <asac> what kind of builder setup are you running?
[15:05] <asac> (all assuming that you use those options on your local build as well ... i only can see the logs from ppa)
[15:23] <fta2> check your config.status after the build, it should match mine
[15:23] <fta2> cdbs adds some parameters by itself
[15:24] <asac> its dpkg-buildpackage apparently
[15:24] <asac> but bzr bd doesn't use that - reason unknown
[15:24] <asac> debuild does neither ... so i suspect that its debuilds fault in the end
[15:25] <fta2> i build with bzr bd
[15:26] <asac> do you see the same flags locally?
[15:27] <asac> -Wl,-Bsymbolic-functions
[15:27] <asac> http://paste.ubuntu.com/5935/
[15:29] <fta2> http://paste.ubuntu.com/5937/
[15:30] <fta2> fta2 crashes, it's the last one from yesterday
[15:30] <asac> hehe
[15:30] <asac> yes. i think its that flag
[15:30] <asac> for me its not used and i don't see the crash. that matches the fact that redhat has no problems. they are unlikely using this.
[15:32] <asac> fta2: ok its obvious why i don't see it ... i use debuild with bzr most of the time, because i usually pass: --builder='debuild -b'
[15:34] <fta2> i don't
[15:34] <fta2> bdm = bd --merge --dont-purge
[15:34] <fta2> bdn = bd --native --dont-purge
[15:34] <fta2> ppa = bd --merge --build-dir=../ppa --builder='dpkg-buildpackage -rfakeroot -S -sa -kB6EE20E8'
[15:34] <fta2> ppa2 = bd --merge --build-dir=../ppa --builder='dpkg-buildpackage -rfakeroot -S -sd -kB6EE20E8'
[15:34] <fta2> ppan = bd --native --build-dir=../ppa --builder='dpkg-buildpackage -rfakeroot -S -sa -kB6EE20E8'
[15:35] <asac> yes
[15:35] <asac> try debuild
[15:35] <asac> i try dpkg-buildpackage after the rebuild without any patch is finished
[15:35] <asac> to see that it really crashes
[15:35] <fta2> no, i prefer to use what the ppa builders use
[15:36] <asac> this is to test if your crash goes away
[15:36] <fta2> otherwise it will work for me but not for the others
[15:36] <asac> not to test that you change your default setup
[15:36] <fta2> oh
[15:36] <asac> if it goes away we can fix it
[15:36] <fta2> I can just set LDFLAGS
[15:37] <asac> yes
[15:37] <asac> you can also wait till my dpkg-buildpackage build is done (which i just started)
[15:39] <asac> i think 28 min :)
[15:39] <asac>  \o/ :)
[15:39] <asac> the crash is triaged :)
[15:39]  * asac happy before anything is done ;)
[15:50] <armin76> http://www.openoffice.org/issues/show_bug.cgi?id=86670
[15:50] <armin76> did you guys saw that?
[15:50] <ubotu> OpenOffice.org bug 86670 in tools "system-mozilla: libxul and new pkgconfig files" [Task,Resolved: fixed]
[15:55] <asac> armin76: yes we have something similar
[15:56] <armin76> on openoffice or xul?
[15:56] <armin76> because oo is using libdir
[15:57] <armin76> with that patch, that is
[15:58] <armin76> MOZ_LIB=`$PKG_CONFIG --variable=libdir libxul`
[15:58] <armin76> i don't have libdir on my pkgconfig files...
[15:58] <fta2> asac, I have the commit ready and i'm building but you will be done before me
[16:01] <asac> u never know
[16:02] <asac> armin76: then they did wrong
[16:02] <armin76> thats why i'm telling you :)
[16:02] <asac> armin76: for 1.9 you must not need rpath
[16:02] <asac> armin76: but maybe it gracefully does what we want if libdir is empty?
[16:03] <asac> what is done with MOZ_LIB
[16:03] <asac> you see that?
[16:03] <armin76> don't think so
[16:03] <armin76> a guy just asked me to add libdir
[16:03] <asac> its obviously not in the patch
[16:03] <asac> no thats not needed
[16:04] <armin76> i know
[16:04] <asac> its most likely that the yuse rpath
[16:04] <asac> but libxul is dependent and thus loaded in an already bootstrapped env
[16:04] <asac> armin76: look in the ubuntu ooo packaage ... there hsould be a patch
[16:07] <armin76> link? :)
[16:11] <asac> fta2: just xulrunner didn't cause the crash
[16:11] <asac> now trying ffox
[16:11] <asac> on top
[16:12] <asac> armin76: i am not sure ther eis a link :)
[16:12] <asac> the smallest you can get is the diff.gzu and apply the debian/ part against an empty directory
[16:13] <fta2> xulrunner alone never crashed
[16:14] <asac> armin76: https://edge.launchpad.net/ubuntu/hardy/+source/openoffice.org/1:2.4.0~rc2-1ubuntu3/+files/openoffice.org_2.4.0~rc2-1ubuntu3.diff.gz
[16:14] <asac> fta2: xulrunner alone with symbolic-functions i mean
[16:14] <asac> using the old ffox
[16:15] <asac> still no crash. i am out of ideas right now
[16:33] <asac> jtv: i found one glitch that might be good to get fixed on lp side
[16:33] <asac> jtv: http://paste.ubuntu.com/5939/
[16:34] <jtv> asac: looking...  btw just implemented the context trick.
[16:34] <asac> thanks ... that is a pattern that is regularly used to include another .dtd
[16:34] <jtv> asac: you had that in a message you showed me the other day, IIRC.  Is it something we generate?  Something we should handle?
[16:34] <jtv> Ah ok
[16:35] <asac> now i am thinking about how we can do that without too much work
[16:35] <fta2> http://starkravingfinkle.org/blog/2008/03/global-extensions-on-linux-and-mac/
[16:35] <jtv> asac: If the other file has a name ending in .dtd, it will be imported anyway and no special handling is in order.
[16:35] <asac> jtv: well... the point is that we don't really have that information :)
[16:36] <asac> atm we only get en-US.xpi exported
[16:36] <asac> further it would be pretty hard to get the info if we get de.xpi alongside for example
[16:36] <asac> jtv: can this be handle as a translation?
[16:37] <asac> e.g. for the special key: "% realBundDTD SYSTEM" ?
[16:37] <asac> the translation parser could see that and produce the right pattern from it
[16:37] <jtv> asac: I'm afraid I don't follow
[16:38] <jtv> How does this syntax work exactly?
[16:38] <asac> ok ... the normal pattern for translatable entities looks like:
[16:38] <asac> <!ENTITY size.label             "Size">
[16:38] <asac> thats mapped to the .po file like
[16:39] <asac> #: .... (size.label)
[16:39] <asac> msgid "Size"
[16:39] <asac> ... and so on
[16:39] <asac> let me think before i go on
[16:39] <asac> yes right
[16:40] <asac> <!ENTITY % something SYSTEM "chrome://...">
[16:40] <asac> would be mapped to
[16:40] <asac> #: .... (% something SYSTEM)
[16:40] <asac> msgid "chrome://...."
[16:40] <asac> jtv: understood?
[16:41] <jtv> But normally it includes another file?
[16:41] <asac> if our parser sees a entity starting with "% " it could create the &something;
[16:41] <asac> jtv: right, but you cannot find that without parsing chrome.manifest
[16:42] <jtv> So you want us to spit it out as a translation message, so your parser can handle it.
[16:42] <asac> right
[16:42] <jtv> Or a special comment maybe?
[16:42] <asac> every file we cannot produce from .po will be copied from en-US.xpi
[16:43] <jtv> And you want to be able to reconstitute the reference.  Gotcha.
[16:43] <jtv> This could take me some time, because I'd have to figure out a lot more about how the DTD parser returns its data to us.  :/
[16:44] <asac> hmm ... you use a real dtd parser that auto resolves entitites?
[16:44] <asac> i assumed you had something hand written :)
[16:46] <jtv> We are not the knights who say NIH
[16:48] <asac> jtv: thats good ... but how do you resolve that entity then?
[16:49] <jtv> asac: that's the problem...  I don't know.  It's something the standard dtd parser does, and I have zero experience with DTD.
[16:49] <asac> or do you ignore failed entity resolves?
[16:49] <asac> jtv: yep ;)
[16:49] <asac> ok
[16:50] <jtv> So you may have to grep for this pattern...
[16:50] <fta2> http://blog.vlad1.com/2008/03/18/a-little-more-cairo-just-for-you/
[16:51] <asac> good
[16:55] <asac> fta2: no crash for me
[17:00] <asac> fta2: do you see that on i386?
[17:02] <fta2> yes
[17:02] <asac> i really don't see that
[17:02] <asac> fta2:  you have an strace ?
[17:05] <asac> fta2: ok stupid me again ;)
[17:06] <fta2> ?
[17:06] <asac> its all fine
[17:06] <asac> i ran my non symbol-functions dev-tree :)
[17:07] <asac> with symbolic-functions it crashes
[17:08] <fta2> seems ok here too
[17:08] <asac> right
[17:11]  * asac happy that he saw symbolic-functions in the log :)
[17:12] <asac> i always knew that we would get struck by that at some point
[17:12] <fta2> the question is now, is the leak patch needed ?
[17:13] <asac> i don't think that kind of hack is needed, no
[17:17] <fta2> trying
[17:18] <fta2> i've updated the case
[17:18] <fta2> giving you credits
[17:18] <fta2> mozilla bug 422463
[17:18] <ubotu> Mozilla bug 422463 in Build Config "configure fails on x86_64 if pyxpcom is enabled" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=422463
[17:25] <asac> fta2: please let me know if they complain on the bug or something
[17:27] <asac> ill try to push for something like timeless suggested i guess.
[17:27] <armin76> yuck
[17:28] <armin76> trunk now needs sqlite-3.5.7
[17:31] <armin76> you guys have it?
[17:31] <armin76> !status sqlite
[17:31] <ubotu> Sorry, I don't know anything about status sqlite - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[17:31] <armin76> or whatever it was the command :P
[17:31] <armin76> !info hardy sqlite3
[17:31] <ubotu> Package hardy does not exist in gutsy
[17:31] <armin76> !info sqlite3 hardy
[17:32] <ubotu> sqlite3 (source: sqlite3): A command line interface for SQLite 3. In component universe, is optional. Version 3.4.2-2 (hardy), package size 19 kB, installed size 84 kB
[17:32] <armin76> woot?
[17:33] <asac> yes sqlite is prone to break things on major version upgrades ;)
[17:38] <xhaker> armin76: i think sqlite is static linked into firefox3
[17:39] <xhaker> oops, libnss-1d depends on the version in the archives
[17:53] <[reed]> GRR
[17:53] <[reed]> fta2: stop reseting the blocking flag!
[17:53] <[reed]> resetting*
[17:53] <asac> again?
[17:53] <asac> booo!
[17:53] <[reed]> yes, again
[17:54] <asac> fta2: everytime we have to get blocking flag back, someone quite busy has to be come around :) ... please remember that and be careful :)
[17:55] <asac> but i assume it a mouse wheel accident
[17:57] <fta2> [reed], how is that possible? it's not a mid-air thing this time.
[17:57] <fta2> I've added a comment to a freshly loaded page
[17:57] <[reed]> mouse wheel, probably
[17:58] <fta2> no, i never clicked on the form in this session
[17:59] <fta2> and I don't get notification for my own changes so I don't know
[17:59] <fta2> well, i could stop updating this bug if you prefer
[18:02] <[reed]> no, but something isn't right on your side
[18:47] <armin76> lolz
[18:47] <armin76> fta2: you can setup the notifications stuff
[19:01] <armin76> uh, did they move back the home button?
[19:02] <armin76> mozilla bug 422420
[19:02] <[reed]> yes
[19:02] <ubotu> Mozilla bug 422420 in General "Revert home button move and related migration code" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=422420
[19:02] <armin76> yay
[19:02] <[reed]> well, didn't move it back, but the move code got reverted
[19:02] <[reed]> if your profile already had it moved, you'll have to move back yourself
[19:04] <armin76> you can't set a preferred homepage now on the default settings?
[19:04] <[reed]> ?
[19:05] <armin76> i'll try with ubuntu :P
[19:50] <fta> [reed], it works without the leak patch too...
[19:52] <fta> i now wonder why -Wl,-Bsymbolic-functions is used by default in ubuntu
[20:07] <asac> fta: it gives performance improvements and is considered safe for most cases.
[20:08] <asac> unless you do something like this :)
[20:10] <fta> so what now. moving jemalloc into a .a was also for a performance improvement reason
[20:10] <fta> we trade an improvement for another
[20:10] <asac> well. i will comment on the bug (unless it already evolved)
[20:11] <asac> moz should link jemalloc into the binaries - as timeless suggested
[20:11] <asac> thats sound
[20:11] <fta> just let me add that it work without the patch too as i said i will, then go on
[20:12] <asac> sure. thought that was already said
[20:12] <fta> ?
[20:12] <asac> that it works without the leak patch ;)
[20:12] <fta> really ? I didn't
[20:14] <asac> ok
[20:18] <fta> checking the flags before i hit submit...
[20:19] <fta> double checking
[20:19] <fta> done
[20:19] <fta> did I drop something ?
[20:21] <asac> what do you mean? uncommit?
[20:25] <fta> no, the flags on bonsai
[20:40] <asac> bugzilla you mean?
[20:40] <asac> launchpad codebrowse is unbearable slow, if not completely locked up
[21:04] <fta> works for me
[21:05] <fta> i find the ppa browsing much slower
[21:41] <fta> http://browsing.justdiscourse.com/2008/03/20/the-mozillawebkit-arms-race/
[21:44] <fta> http://dothetest.co.uk/
[21:44] <asac> mozilla bug 404627
[21:44] <ubotu> Mozilla bug 404627 in DOM "[FIX]XPinstall whitelist bypass using refresh after fix for bug 402649" [Normal,Verified: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=404627
[21:45] <asac> mozilla bug 372075
[21:45] <ubotu> Mozilla bug 372075 in DOM "javascript: URI evaluation should use sandboxed context for toString, etc" [Major,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=372075
[21:45] <asac> mozilla bug 282660
[21:45] <ubotu> Mozilla bug 282660 in JavaScript Debugger "Crash [@ jsds_NotifyPendingDeadScripts] ds->script is null" [Critical,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=282660
[21:45] <asac> mozilla bug 399298
[21:45] <ubotu> Mozilla bug 399298 in Security "Bypassing XPCNativeWrapper by redefining XPCNativeWrapper" [Normal,Verified: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=399298
[21:45] <asac> mozilla bug 397427
[21:45] <ubotu> Mozilla bug 397427 in Style System (CSS) "[FIX]Stylesheet href property shows redirected URL unlike other browsers" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=397427
[21:45] <asac> mozilla  bug 419350
[21:45] <ubotu> Mozilla bug 419350 in XPCOM "[ia64] build failure using gcc 4.3" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=419350
[22:17] <armin76> guys, any thoughts why http://dev.gentoo.org/~armin76/ff3srio.png looks so ugly? browse with your ff and you'll see if cool
[22:17] <armin76> s/if/it
[22:20] <asac> armin76: looks ugly yes
[22:20] <asac> bad webdesigner
[22:20] <armin76> lol
[22:20] <armin76> see it in your ff3
[22:20] <armin76> www.santanderrio.com.ar
[22:24] <fta> http://www.sofaraway.org/ubuntu/tmp/santanderrio.png
[22:27] <fta> armin76, yours is ugly indeed
[22:28]  * fta blames armin76 
[23:05] <Jazzva> Evening...
[23:05] <Jazzva> asac: I came back :)...
[23:06] <asac> Jazzva: hey
[23:06] <asac> :)
[23:07] <Jazzva> It feels good when exams are over :)
[23:08] <Jazzva> So, I ran the script that checks for new extensions that are not added to gnome-app-install... I noticed some new packages there. Should they be added?
[23:10] <asac> Jazzva: yes. that would be a good thing
[23:10] <asac> howver, i would first like to add a few more extensions
[23:10] <asac> there are already a bunch new extensions in the pipeline
[23:11] <asac> in code.launchpad.net/firefox-extensions
[23:11] <asac> i did a session about packaging extensions and wrote a simple helper .mk file to make writing debian/rules trivial for most extensions
[23:11] <asac> that can be found at https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/Packaging
[23:12] <asac> https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions
[23:12] <asac> there is a page where we add extensions we are working on .. or suggest for addition :)
[23:13] <Jazzva> Ok, I'll check them out now :)
[23:13] <asac> if you have more xtensions in mind :) ... fill them in
[23:17] <asac> another i pointed that has proper licensing is all-in-one-sidebar
[23:17] <asac> its compatible with ffox 3 afaik
[23:18] <asac> but there should be plenty more
[23:34] <Jazzva> Well, I checked the extensions I use and I have found three that have appropriate licenses and work with FF 3.0b5pre (Greasemonkey, Better Gmail 2, Bettersearch). I suppose that Better Gmail is also licensed under GPL. I'll add them to the list now. Pmog and Stumbleupon works with FF, but I don't think they're licensed under any of mentioned licenses... I can't find any info so far.
[23:35] <Jazzva> asac ^
[23:35] <asac> Jazzva: greasemonkey has a package in the archive that needs to be upgraded
[23:36] <asac> at best its redone using the new xpi.mk
[23:36] <asac> but is a bit trickier as you need to process .idl files during build.
[23:37] <Jazzva> What are .idl files?
[23:37] <asac> xpcom interface definitions
[23:38] <asac> xpcom component are cross language. e.g. you can call them from javascript and C++.
[23:38] <asac> so you need a language independent description of such components. thats basically what idl is :)
[23:39] <Jazzva> aham... I see. So, could I find how to process them in debian/rules in the old package :)?
[23:39] <asac> yes
[23:39] <Jazzva> Great :)
[23:39] <asac> i think you have to call all using the xpidl compiler in the xul dev package
[23:41] <Jazzva> Ok, I'll just go through the rules file and see if I can see what it's doing.
[23:41] <asac> Jazzva: the right path to run this is:
[23:41] <asac> `pkg-config --variable=sdkdir libxul`/bin/xpidl
[23:41] <fta> libxul?
[23:41] <asac> e.g. its not in /usr/bin/ anymore since xulrunner-1.9
[23:42] <fta> nm
[23:42] <asac> well ... its just to get the xulrunner-1.9 sdk dir
[23:42] <asac> do echo `pkg-config --variable=sdkdir libxul`/bin/xpidl
[23:42] <asac> to see what i mean :)
[23:43] <Jazzva> i see... it's in /bin :)...
[23:43] <asac> yeah ... but the version is in the path so you cannot use a fixed path
[23:44] <Jazzva> mhm... Ok
[23:45] <Jazzva> So, is it ok to add better gmail (2) to the list, as they're not in the archives?
[23:45] <fta> is there a gnome applet to see the cpu temp ?
[23:45] <Jazzva> i think there is
[23:46] <Jazzva> i saw it on some screenshots
[23:46] <fta> do you know the name ?
[23:46] <Jazzva> just a sec...
[23:47] <Jazzva> You should install lm_sensors and gnome-applet-sensors in order to do that, afaics...
[23:48] <Jazzva> i'm not sure if those are the right names
[23:48] <Jazzva> but they should be similar to that...
[23:49] <fta> k
[23:49] <Jazzva> lm-sensors and sensor-applet
[23:53] <Jazzva> nope, better gmail is compatible only up to 3.0b2