[00:10] <crimsun> fta: i use the non-Free Nvidia driver, so for me, no.
[00:10] <fta> crimsun, me too so thanks, i keep xorg on hold
[00:12] <asac> fta: no ... cannot handle automatically. its a driver issue in the end
[00:12] <asac> you can do you own hacky scripts though in user space ;)
[00:13] <fta> can't it be properly done in jaunty?
[00:13] <asac> unsure. maybe a few more drivers get fixed to do it properly
[00:14] <asac> i know that there is work in progress
[00:14] <asac> to make option drivers do the same as the ones that already work
[07:26] <fabrice_sp> Hi. I was looking at flashblock package, because the version in Jaunty wasn't the last, one, and I saw that this package is built from CVS checkout, ignoring the normal upstream versions (jaunty => flashblock-1.3.11a~snapshot20081113, author = 1.5.7.1). Won't it be better to repackage it from scratch?
[07:28] <crimsun> fabrice_sp: looking at the version (snapshot date), 1.5.7.1 wasn't available.
[07:29] <crimsun> fabrice_sp: now that it is, you should be able to modify it if you feel up to it =)
[07:29] <fabrice_sp> sure, but isn't there a risk of checking out a non stable version if you use directly CVS?
[07:30] <crimsun> sure, but you can modify the packaging...
[07:30] <fabrice_sp> crimsun,: as it would be a repackaging, it should go through REVU?
[07:31] <crimsun> why would it be a repackaging?
[07:31] <crimsun> you're changing debian/rules
[07:31] <fabrice_sp> ohhh, you're right
[07:32] <fabrice_sp> and I can download the xpi file, and uncompress it
[07:33] <fabrice_sp> will create the bug report and assign it to myself (Hoping to find a sponsor to ack it afterwards :-) )thanks for your answer
[07:34] <crimsun> yw
[10:00] <RzR> i just missed fabrice
[10:01] <RzR> hi fabrice_sp
[10:01] <RzR> let me explain
[10:01] <RzR> i just read your posts
[10:02] <RzR> the author has a weird release process
[10:02] <RzR> and I still think using the CVS tree is better for us
[10:02] <RzR> current one is working on jaunty right ?
[10:06] <fabrice_sp> Hi RzR.
[10:07] <fabrice_sp> This is partly why I asked, because if it has been done this way, I assume it's for some good reason.
[10:07] <fabrice_sp> Anyway, it's hard to know which version we have in ubutnu, since we only have the cvs date, and no real release in front of that
[10:10] <fabrice_sp> I have to check how it works in Jaunty, but you agree with me that there is a risk to get a buggy version using CVS
[10:13] <RzR> it the CVS belonging to the release
[10:13] <RzR> I should explain this into debian/README.source
[10:14] <RzR> I am afraid CVS is the only way to get the sources
[10:14] <RzR> am i right ?
[10:15] <RzR> so please contact me if you plan to help to flashblock, we'll work toguether
[10:16] <RzR> remaining tasks is to test jaunty version and backport it to intrepid and hardy
[10:16] <RzR> I'll work on it debian side if you can take care of this
[10:16] <fabrice_sp> what do you mean by source? Because you can get a .xpi with the watch file
[10:17] <RzR> I want to rebuilt it from scratch then anyone can understand this
[10:17] <fabrice_sp> Anyway, as I am nobody here, I won't discuss decisions that have already been taken by more senior people...
[10:17] <fabrice_sp> my mess came from the version scheme
[10:18] <RzR> ok I'll doccument it
[10:18] <RzR> have you tested jaunty ?
[10:19] <fabrice_sp> I just tested the 1.5.7.1 in Intrepid
[10:19] <fabrice_sp> that's all
[10:19] <fabrice_sp> (I packaged it in the meanwhile)
[10:20] <RzR> can you  install jaunty deb into intrepid just to test
[10:21] <fabrice_sp> ok
[10:21] <fabrice_sp> I'll do that
[10:22] <RzR> great
[10:22] <fabrice_sp> (and it would be great if next version of package would have the real upstream based version)
[10:22] <fabrice_sp> :-)
[10:22] <RzR> I'll explain you how it works
[10:22] <RzR> because it's weird
[10:23] <RzR> it took me time to understand
[10:23] <fabrice_sp> :-)
[10:24] <RzR> anyway welcome to this channel
[10:24] <RzR> i didnt notice you were there
[10:25] <fabrice_sp> the same happened to me with you (I was wondering who were rzr@users.sf.net) :-)
[10:25] <RzR> btw i have an other project pending for this team
[10:26] <RzR> it's testing a VRML plugin
[10:26] <RzR> but everyone seems busy
[10:27] <fabrice_sp> logical: between updates and new release, there is a lot to do
[10:27] <fabrice_sp> I came to flashblock doing merge/sync for jaunty,
[10:29] <fabrice_sp> By the way, I create a bug report for that 'update' and I was working on it (bug #315718). What do I do with it?
[10:32] <RzR> fabrice_sp: I think it's prefered to merge jaunty one into intrepid, you can close it and open an other one
[10:32] <RzR> just branch update debian/changelog and propose it
[10:32] <RzR> i'll do this if i can test intrepid
[10:33] <RzR> but I dont have intrepid
[10:33] <RzR> i am gone
[10:33] <RzR> thx again fabrice_sp
[10:46] <fabrice_sp> I'll check the Jaunty versions in Intrepid, anyway
[10:47] <fabrice_sp> thanks !
[11:47] <halkok> Hello! I have a question I was hoping for some help with: The setting "nglayout.initialpaint.delay" in FF about:config is nifty. BUT, is there any way to have customized per page settings for this variable? Like, 250ms for www.example.com and 1000 for www.otherexample.com?
[12:25] <asac> fta_: could you push bzr rev 404 of 1.9.2 xul to your PPA?
[12:26] <asac> not now ;) ... i think DX flks would be happy to havea  libnotify xul for testing
[12:27] <asac> fabrice_sp: talk to Jazzva_ please about extensions
[12:28] <asac> fabrice_sp: if you do something please do it in the bzr branches ;)
[12:28] <asac> and let us sign off your work before you get it uploaded. thanks!
[12:55] <notrelevant> Hello! I have a question I was hoping for some help with: The setting "nglayout.initialpaint.delay" in FF about:config is nifty. BUT, is there any way to have customized per page settings for this variable? Like, 250ms for www.example.com and 1000 for www.otherexample.com?
[13:03] <asac> notrelevant: why do you want that?
[13:04] <asac> anyway ... i doubt there is a per-page setting
[13:04] <notrelevant> Because at my work.. there is one specific page.. which needs to be updated often.. and in addition it is slow response... and after working full time a week it drives me mad
[13:05] <notrelevant> I know there isn't a plugin or anything..
[13:05] <notrelevant> but maybe there is a clever way to do it
[13:06] <notrelevant> What I would achieve is that I don't have to see the redrawing of the page every interval it refreshes... (as the page only modifies slightly everytime changing that setting will make it update seamlessly)
[13:07] <notrelevant> anyone got any ideas how to cook up something ?
[13:08] <asac> let me check
[13:10] <asac> you need to make layout/base/nsPresShell.cpp aware of per-page prefs for pagination delay
[13:14] <notrelevant> hmm
[13:14] <notrelevant> ok.
[13:14] <notrelevant> This is only for one single page
[13:14] <notrelevant> the rest can be set to default
[13:15] <notrelevant> So basically this is something I need to script
[13:15] <notrelevant> ?
[13:15] <notrelevant> there's noe simple fix/one-liners ?
[13:15] <notrelevant> :)
[13:22] <asac> notrelevant: script isnt possible ... thats in c++
[13:22] <asac> you need to add a new feature in that code
[13:26] <asac> @time
[13:29] <notrelevant> allright... that is above my head. Thanks for pointing me in the right direction anyway :)
[13:29] <asac> sorry ...ur welcome notrelevant
[13:34] <rZr> hi hny2k9, are you guys going to fosdem ?
[13:36] <fta_> asac, DX folks?
[13:59] <asac> fta: those folks doing the new notification stuff
[14:00] <asac> rZr: not yet sure
[14:05] <fta> asac, done
[14:11] <asac> thx
[14:12] <asac> ok travelling
[14:12] <fta> i need to add a depend on libcanberra0 too
[14:12] <rZr> i am unsure too
[14:12] <rZr> but this will be good
[14:13] <rZr> i'll may also go the gsm expo in barcelonna
[14:24] <fta> asac, damn, libcanberra0 is not on all arches, and not on hardy.
[15:50] <asac> at beenm added to ffox too?
[15:50] <asac> fta: oops ... i means : was libcanberra been added to ffox too? or just for tbird?
[15:50]  * asac cannot type with gloves on
[15:58] <asac>     * jaunty sparc Successfully built (DONE)
[15:58] <asac>     * jaunty powerpc Successfully built (DONE)
[15:58] <asac>     * jaunty lpia Successfully built (DONE)
[15:58] <asac>     * jaunty ia64 Successfully built (DONE)
[15:58] <asac>     * jaunty i386 Successfully built (DONE)
[15:58] <asac>     * jaunty hppa Successfully built (DONE)
[15:58] <asac>     * jaunty armel Successfully built (DONE)
[15:58] <asac>     * jaunty amd64 Successfully built (DONE)
[15:58] <asac> libcanberra that is
[15:59] <asac> but right. a bit of a pity ... but we can add that lib to PPA just
[15:59] <asac> as backports
[16:01] <asac> ok off for a while ... preparing for train ride ;)
[16:01] <asac> cu later
[16:30] <armin76> bye
[17:34] <fta> asac, it's loaded dynamically so it's meant for ff and tb, or xul and tb. with the latter, xulapps get it for free
[17:35] <fta> asac, http://packages.ubuntu.com/search?keywords=libcanberra&searchon=sourcenames&suite=all&section=all
[18:10] <asac> fta: how is it dynamically loaded? dlopen or by being linked against an optional component like mozgnome?
[18:14] <fta> asac, http://hg.mozilla.org/mozilla-central/rev/a873ac2554396b2984523c13952fe89c4758daf2#l89
[18:15] <fta> there's nothing in configure :(
[18:16] <asac> fta: looks good. we dont need it at build time ;)
[18:17] <asac> so adding a Recommends to xulrunner should be sufficient
[18:17] <asac> (unless KDE folks go mad again)
[18:17] <asac> (in that case Suggests)
[18:17] <fta> sure but if it's not at build time, we look the ${shlibs:Depends} magic
[18:17] <asac> fta: yes. thats why we should add a Recommends
[18:17] <asac> it isnt mandatory anyway
[18:17] <fta> i checked, it could be in Depends, it doesn't drag gnome libs with it
[18:18] <asac> fta: it does
[18:18] <asac> fta: libpulse
[18:18] <asac> Recommends is good
[18:18] <asac> thoguh
[18:18] <asac> question is whether suggests. depends isnt needed i think
[18:18]  * asac on a call
[18:18] <fta> no, it doesn't drag pulse in, http://packages.ubuntu.com/intrepid/libcanberra0
[18:20] <asac> $ apt-cache show libcanberra0 | grep libpulse
[18:20] <asac> Depends: libasound2 (>> 1.0.18), libc6 (>= 2.4), libltdl7 (>= 2.2.4), libogg0 (>= 1.0rc3), libpulse0 (>= 0.9.8), libtdb1, libvorbis0a (>= 1.1.2), libvorbisfile3 (>= 1.1.2)
[18:21] <fta> hm
[18:21] <asac> look in jaunty (http://packages.ubuntu.com/intrepid/libcanberra0 is intrepid)
[18:21] <fta> bad then
[18:22] <asac> Recommends: is ok imo  ... does what we want on gnome and probably kde will complain ... but lets wait for that first
[18:22] <asac> or add it as Depends: explicitly of -gnome-support
[18:22] <asac> s/of/to/
[18:24] <fta> i need to ask to mventnor if there's a minimum version of libcanberra required, otherwise, it need to put that in my ppa too
[18:24] <fta> I already have 99 packages :P
[18:25] <asac> fta: you can ... but you dont need to ;)
[18:25] <asac> its optional after all ;)
[18:25]  * fta should not type with frozen hands
[18:26] <asac> hopefully the SONAME version properly reflects canberra requirements:
[18:26] <asac> libcanberra = PR_LoadLibrary("libcanberra.so.0");
[18:26] <asac> so if we believe in the mightiness of canberra folks this means that they didnt break ABI ;)
[18:27] <fta> it's a really young library, i have serious doubts
[18:27] <asac> yeah ;) ... we should discover that then and request demotion from main if they proofed that they didnt care about ABI
[18:28] <asac> but from what i see just a very few symbols are used by moz
[18:28] <fta> it's a dep of epiphany-*
[18:28] <asac> http://paste.ubuntu.com/103214/
[18:28] <asac> so hopefully those are stable
[18:28] <asac> yeah. i assume its properly tracked ABI then
[18:28] <asac> if it breaks we have to hunt them down
[18:29] <asac> so in theory intrepid version should be ok too
[18:30] <fta> well, read the bug
[18:30] <fta> > +typedef struct _ca_context ca_context;
[18:30] <fta> >
[18:30] <fta> > Is it worth copying this stuff from libcanberra, or should we just have a
[18:30] <fta> > configure check so that this code is only built when libcanberra dev headers
[18:30] <fta> > are installed?
[18:30] <fta> Definitely worth it, maybe reconsider at a later stage. libcanberra is very
[18:30] <fta> new, only GNOME 2.24 has it as a new dependency.
[18:30] <asac> yes ... so all fine imo
[18:31] <asac> either make a hard depends on moz-gnome-support
[18:31] <asac> or a Recommends: on xulrunner-1.9
[18:31] <asac> i guess the former is what we want without causing fud among kde folks
[18:32] <fta> i already made it Recommends: of xul 1.9.1/2. i'm tempted to make it a Dep of -*gnome-* too but for that, i must push it to my ppa
[18:33] <fta> because i do all my stuff for hardy too
[18:33] <asac> fta: hmm ... didnt you say you pushed a new xul 1.9.2 snapshot with my last commit?
[18:33] <asac> all fine. just have find out what you referred to with "done" ;)
[18:33] <fta> too bad i don't have stats for my ppa, i would seriously consider dropping things that are no longer needed
[18:34] <fta> last commit of when? i did xul yesterday eve
[18:34] <asac> fta: you should ask pitti ... i think he has some nice scripts used to identify rotten things in the main archive
[18:34] <asac> e.g. stuff that is in main, but doesnt have a depends in main anymore
[18:34] <asac> and so on
[18:35] <fta> how will it help me?
[18:35] <asac> and a bunch of other consistency scripts
[18:35] <asac> fta: it will find stuff that isnt required anymore ;)
[18:35] <fta> i just need usage stats
[18:35] <asac> hmm
[18:35] <asac> well
[18:35] <asac> thats a differen thing then ;)
[18:35] <fta> yes
[18:35] <asac> i would say that you shouldnt feel obliged to continue stuff for which you never get any feedback
[18:36] <asac> just keep the head builds for now ... until we have ~ubuntu-mozilla-daily or something
[18:36] <asac> :)
[18:36] <asac> i just feel relucaant to add new teams for each and every use case... since soon multi-ppas-per-user/team will be available
[18:38] <fta> i thought about ubuntu-mozilla-releases with just milestones, not snapshots
[18:38] <asac> fta: yeah. we can have plenty of topics
[18:39] <asac> ubuntu-mozilla-milestones, ubuntu-mozilla-per-commit
[18:40] <asac> i will check when multi PPAs will land
[18:40] <asac> if thats longer than one month ahead i am not sure i want to wait ;)
[18:41] <asac> also stuff like:
[18:41] <asac> ubuntu-mozilla-ports-1.9.2 (e.g. every embedding stuff built against 1.9.2 snapshots)
[18:42] <asac> auto triggered respins when xulrunner receives a new commit ;)
[18:42] <asac> fun
[18:42] <asac> probably a waste of power though ;)
[18:47] <fta> no way it could work with our work-flow. It would need partial rebuilds
[18:47] <fta> at least for trunk
[18:50] <fabrice_sp> asac: about your previous comment. Does that mean that all the extension changes has to be done in bazar? Even things like the one in Bug #286225?
[18:51] <fabrice_sp> (and is there a kind of tutorial/wiki on bazar usage. If for extension, better!)
[18:51] <fabrice_sp> I'm refering to this one: <asac> fabrice_sp: if you do something please do it in the bzr branches ;)
[18:54] <asac> fabrice_sp: no. would be beneficial to move that to bzr, but if its synched from debian we can keep it out
[18:56] <asac> fabrice_sp: if you start to package something new, take a look at https://wiki.ubuntu.com/MozillaTeam/Extensions ... there are packaging links too
[18:56] <asac> fta: what do you mean by "partial rebuilds"?
[18:56] <asac> you mean PPAs wont be able to catch up?
[18:57] <asac> to produce a package for each and every commit in -central?
[18:57] <asac> jcastro: gwibber crashed on me :/ no crash file though
[18:58] <asac> i sent something ... it disappeared ... i thought it was not send and i rewrote it and posted ... suddenly both popped up
[19:04] <fta> maybe we should restart update-notifier, it keeps a file descriptor open
[19:05] <fta> Warning: The following processes are using deleted files:
[19:05] <fta>          Process: /usr/bin/update-notifier    PID: 8061    File: /var/lib/update-notifier/user.d/firefox-3.1-restart-required
[19:07] <fta> Upload Warnings:
[19:07] <fta> PPA exceeded its size limit (6319.00 of 5120.00 MiB). Ask a question in https://answers.launchpad.net/soyuz/ if you need more space.
[19:09] <asac> i had sudden death of system
[19:09]  * asac rebooted
[19:09] <asac> darn
[19:09] <asac> this upgrade wasnt good
[19:09] <asac> everything is slow as hell
[19:09] <asac> damn
[19:09] <asac> damn damn
[19:09] <asac> all worked well
[19:09] <asac> now i am doomed
[19:10] <asac> maybe Xorg breakage for sure
[19:12] <asac> wft XOrg 97% :(
[19:12] <asac> fail!
[19:13] <asac> * Disable terminal function entirely * Add x11fnc.sh to provide several general purpose X bash functions
[19:14] <asac> could it be that?
[19:15] <fta> donno, i have X on hold until they solve the nvidia mess
[19:18]  * asac tries something
[19:24] <asac> fta: 20:22 < asac> bryce: tjaalton: seems like enabling exa caused this. going for Xaa makes things go back to normal  (https://edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/1:6.9.0.91-1ubuntu3)
[19:24] <asac> 20:22 < asac> bryce: tjaalton: what info do you need? i would love to have this fixed ... but in worst case we have to  exclude this card from exa i think. let me knew
[19:24] <asac> so i am lucky and back to normal :)
[19:24]  * asac rides the bleeding edge
[19:24] <fta> :)
[19:27] <fta> i have a bunch of /tmp/plugtmp/plugin--xxxx left behind
[19:27] <fta> Warning: File '/tmp/plugtmp/plugin--1171' (score: 210) contains some suspicious content and should be checked.
[19:27] <fta> Warning: File '/tmp/plugtmp/plugin--2758' (score: 200) contains some suspicious content and should be checked.
[19:27] <fta> Warning: File '/tmp/plugtmp/plugin-' (score: 210) contains some suspicious content and should be checked.
[19:27] <fta> Warning: File '/tmp/plugtmp/plugin--1012' (score: 210) contains some suspicious content and should be checked.
[19:27] <fta> etc..
[19:27] <fta> firefox ?
[19:33] <asac> hmm
[19:33] <asac> short live bug 315889
[19:59] <ddeath> Hi
[19:59] <ddeath> I would like to swap button set on awesomebar activation/deactivation event
[20:00] <ddeath> I have found openAutocompletePopup method, but I need rather something like popuphidde
[20:00] <ddeath> method
[20:06] <saivann> asac : ping
[20:09] <asac> saivann: yes?
[20:09] <wikz> fta: what's the diff between install/$(DEB_MOZ_APPLICATION):: and the .install files ?
[20:10] <saivann> asac : I wanted to know if you still have someone who's working to setup rosetta for thunderbird/sunbird/lightning translation in ubuntu?
[20:10] <fta> wikz, in the *.install files, you cannot rename anything, and you can't do anything conditionally
[20:10] <wikz> fta: apart from permissions can be set in the rules file?
[20:10] <asac> saivann: hard to say ;) ... i hoped for full xpi support before the roll out
[20:11] <wikz> fta: and which one superseedes the other? I mean if I have the same set of files, will it have any adverse effect
[20:11] <ddeath> Where can I find help about developing firefox
[20:11] <saivann> asac : Does that need some changes in rosetta itself? If no, I can start working on this
[20:11] <asac> ddeath: http://developer.mozilla.org/
[20:12] <fta> wikz, both are applied, i think the files are first but you should not depend on that
[20:13] <asac> saivann: i think there are multiple steps: 1. get the template whitelisted, so that builds/uploads get digested and the template taken from there
[20:13] <fta> asac, http://www.sofaraway.org/ubuntu/tmp/mozcentral-commits.png
[20:13] <wikz> fta: reason is that I need to get rid of the executable-not-elf-or-script warnings and I was thinking if I take the install -m route, it is the best. what do you say ?
[20:13] <asac> 2. get me to enabling more applications for po2xpi on an internal host that does the translation for rosetta now
[20:14] <asac> fta: mark said that he would like to be able to have per-commit builds in his opening speech at UDS ... didnt he say that ;)?
[20:14] <fta> wikz, i have a fix perm rule already in the xul & ff packages
[20:14] <asac> afair he explictily mentioned firefox in his example ;)
[20:14] <fta> asac, yes, i wanted to have details on that but noone i asked knew
[20:15] <asac> fta: the details are: do it ;)
[20:15] <fta> asac, I have the bot but not the h/w
[20:15] <asac> fta: i think if we have it and there are not enough resources, we can probably raise this and disable the "per-commit" thing to be a "three-builds a day" or something
[20:16] <saivann> asac : Mmh :-/ I guess there's nothing in these steps that I can work on?
[20:16] <asac> fta: can you plumber a script together that does that so i can run that on some internal host from where we can upload tarballs in a second?
[20:16] <asac> saivann: you can
[20:16] <asac> saivann: you can get the first step done ... talk to arnegoetje
[20:16] <asac> saivann: ask him "why arent the thunderbird templates there"
[20:17] <asac> but first:
[20:17] <asac> check that after a tbird build there is a directory debian/lp-xpi-export/ or something
[20:17] <asac> but now that i think about it ;)
[20:17] <asac> saivann: can you please try to build depend on mozilla-devscripts for tbird
[20:18] <asac> and look in debian/rules of firefox 3
[20:18] <asac> # translation flags
[20:18] <asac> MOZ_TRANSLATION_AUTO_XPI_OUTDIR := debian/lp-export-xpis/
[20:18] <asac> MOZ_TRANSLATION_AUTO_XPI_SEARCHDIRS := debian/$(DEBIAN_NAME)
[20:18] <asac> MOZ_TRANSLATION_AUTO_XPI_LOCALE := en-US
[20:18] <asac> include /usr/share/mozilla-devscripts/lp-locale-export.mk
[20:19] <asac> also look at the binary-post-install/$(DEBIAN_NAME):: in firefox 3 debian/rules
[20:19] <fta> asac, I can upload in a few secs from work too ;)
[20:19] <asac> there we add the install.rdf to the en-US.xpi (which is produced from lp-locale-export.mk automagically)
[20:19] <saivann> asac : I see, this is how Firefox is actually translated, right? That means that I can use it as a good example for Thunderbird?
[20:20] <asac> saivann: yes
[20:20] <asac> saivann: you need to provide the template to launchpad
[20:20] <asac> putting a en-US.xpi in debian/lp-export-xpis/ serves for that purpose
[20:20] <asac> the lp-export-export.mk is what produces a langpack .xpi from a build-tree
[20:21] <saivann> asac : This is the first time that I do this, I'll begin and see if I get some relevant work
[20:21] <asac> saivann: yeah. should be not too hard. first stell. add the lines from above to debian/rules
[20:21] <asac> second step: verify that a build really has something in MOZ_TRANSLATION_AUTO_XPI_OUTDIR after the build has finished
[20:22] <ddeath> There's not seperate IRC channel??
[20:22] <asac> if thats the case you just need to add the install.rdf somehow ... because that file cannot be magically produced by lp-locale-export.mk
[20:22] <asac> ddeath: for what?
[20:22] <ddeath> For developing question
[20:22] <asac> what kind of question?
[20:22] <ddeath> For example for extension maker
[20:22] <asac> extension stuff is definitly different channel than firefox core stuff ;)
[20:22] <ddeath> I will changing icons on awesomebar in some events(on focus)
[20:22] <ddeath> And I can do it.
[20:23] <saivann> asac : Thank you very much for these informations, I'll start working and get back to you once I'll have some work done
[20:23] <ddeath> But I cannot receive situation if user exit from popup
[20:23] <asac> ddeath: you mean "mouse leave" event?
[20:24] <asac> saivann: thanks. start with tbird from bzr branch is probably the best ;)
[20:24] <ddeath> Not.
[20:24] <asac> (or apt-get source jaunty) ;)
[20:24] <ddeath> Somethink like focus stollen
[20:24] <ddeath> Events which occurs when popup hiddes
[20:24] <ddeath> (disappear)
[20:28] <asac> ddeath: maybe you could use .css to achieve what you want?
[20:29] <ddeath> :focus pseudoclass??
[20:29] <ddeath> Maybe
[20:29] <asac> something like that yes.
[20:29] <ddeath> I don't see
[20:29] <asac> i think would be more practical as doing all the addEvent/removeEventListener
[20:29] <asac> at some point forgetting something and then messing memory up ;)
[20:29] <asac> hehe
[20:29] <saivann> asac : Oh, thanks for the hint :)
[20:31] <asac> ddeath: you can basically listen for everything for everything: like: http://mxr.mozilla.org/mozilla-central/search?string=addEventListener shows a bunch of things
[20:31] <asac> ddeath: anyway, I think #extdev on irc.mozilla.org is the resource you want ;)
[20:32] <ddeath> Thank
[20:47] <wikz> fta: the file spicebird in the root directory is the main app launcher and is marked executable but doesn't start with a #!/bin/sh which and so lintian complains. what should I do? use a lintian override?
[20:48] <wikz> fta: the fix-perm worked wonderfully otherwise, thanks :)
[20:48] <fta> wikz, the idea of my fix perm is also to log, so it could be reported and fixed upstream
[20:49] <fta> wikz, by app launcher, you mean *.desktop file or a script in /usr/bin?
[20:49] <wikz> fta: yes
[20:49] <wikz> fta: in fact it has a #!/bin/sh line but it's commented out. I will report upstream who sits next to me :)
[20:50] <wikz> fta: http://paste.ubuntu.com/103268/
[20:51] <fta> yep bad, line 37 must be 1st
[20:52] <wikz> fta: also about the xpm warning. since 0.7 has already been tagged how should I rectify the warning, we had a png for a menu icon
[20:53] <fta> you have both?
[20:54] <wikz> we have an xpm but it's 48X48
[20:54] <wikz> so another problem
[20:54] <wikz> so even if I link to it, it complains
[20:54] <wikz> menu-icon-too-big /usr/share/pixmaps/spicebird.xpm: 48x48 > 32x32
[20:55] <fta> don't you have a png somewhere in the tree?
[20:55] <wikz> yup I do
[20:57] <fta> can't you use that?
[20:59] <wikz> fta: but lintian says not to use pngs for menu :E: spicebird: menu-icon-not-in-xpm-format /usr/share/pixmaps/spicebird.png . If that is acceptable, then I will go for a lintian override.
[21:01] <fta> wikz, i would use a png or a svg and use "Icon=foo" without extension in the desktop file, that's perfectly fine. imho, xpm should be deprecated
[21:02] <wikz> fta: :)
[21:03] <fta> perfectly fine.. in ubuntu. for debian, i don't know how picky they are for that
[21:07] <wikz> fta: well, I will tell them upstream doesn't provide any ;)
[21:10] <fta> mozilla dropped support for xpm last year
[21:15] <fta> https://edge.launchpad.net/ubuntu/jaunty/+source/openoffice.org/1:3.0.1~rc1-2ubuntu1  !!
[21:15] <fta> at last
[21:18] <asac> urgh ... scary
[21:18] <asac> update-initramfs: Generating /boot/initrd.img-2.6.27-7-generic
[21:18] <asac> Segmentation fault
[21:19] <asac> help ... now its:
[21:19] <asac> update-initramfs: Generating /boot/initrd.img-2.6.27-9-generic
[21:19] <asac> Illegal instruction
[21:19] <asac> Segmentation fault
[21:19] <asac> the beginning of the end?
[21:21] <fta> you're doomed
[21:21]  * asac doesnt want a broken initramfs :(
[21:21] <asac> and this happens after i invested about an hour to get this system working without monitor (e.g. had to remove graphics card)
[21:23] <fta> openoffice.org_3.0.1~rc1-2ubuntu1.diff.gz  (95.8 MiB)
[21:23] <fta> lol, 100M compressed
[21:23] <fta> openoffice.org_3.0.1~rc1.orig.tar.gz  (319.7 MiB)  d'oh!
[21:24] <asac> ok creawting a new ramfs
[21:24] <asac> please please please
[21:24] <asac> it worked \o/
[21:25] <asac> but dpkg --configure -a tries it again :(
[21:25]  * asac prays
[21:25] <asac> and reboots
[21:26] <asac> ok no ping anymore :( ... lets hope it comes back ;)
[21:27] <asac> what makes this even more shaky is the fact that its the first server running with NM-only in the universe i guess ;)
[21:27] <asac> its back!!!!
[21:27] <asac> i always new that NM is superior :-)
[21:28] <asac> s/new/knew/
[21:33] <wikz> fta: why doesn't sb not show up in system>preferences>preferred applications ? isn't a .menu file enough?
[21:34] <wikz> s/not//
[21:35] <fta> preferred application is not using .menu
[21:38] <fta> it's directly in gnome-control-center
[21:38] <asac> hard-coded
[21:38] <asac> someone should step up and make that configurable
[21:38] <asac> though i even heard that gnome folks said that making it too easy to change wasnt good (though idont see much sense in it)
[21:39] <fta> last year, i patched it to add ff3.0 => http://launchpadlibrarian.net/11676540/gnome-control-center_2.21.90-0ubuntu2~fta1.diff.gz
[21:39] <fta> apps should be able to register themselves in there
[22:01] <asac> yeah i agree
[23:12] <white> asac: so, i am somewhat online now :)
[23:12] <white> asac: pretty cold here actually :/
[23:12] <white> asac: can you prepare and upload fixed xulrunner packages to stable-security? Looks like I'll take that DSA as well :)
[23:12] <white> asac: and are you doing iceweasel or should I talk to Eric?
[23:13] <white> asac: i can also help you tomorrow, I'll have more time then :)
[23:14] <asac> white: eric is responsible for iceweasel
[23:14] <asac> ;)
[23:14] <asac> i can look into xul tomorrow too then
[23:14] <white> cool, thanks :)
[23:45] <fta> asac, seamonkey needs love in ubuntu too :(