[01:15] <asac> Ubulette: maybe its even enough to run make install (with --prefix=/usr/local) ... to test how well a firefox-gp/trunk build would (not-) work if build --with-system-xul
[01:15] <asac> i doubt that it will *just work* (TM)
[01:15] <asac> but who knows ;)
[01:33] <Ubulette> too bad ppa are so limited in term of archs
[01:33] <Ubulette> will not help us figure out what's wrong with ff3
[01:39] <Ubulette> asac, btw, don't you or mike maintained xulrunner in a tree of some kind ?
[02:28] <Ubulette> asac, it's similar to 1.8.*
[06:52] <shirish> asac: Ubulette: either of you up guys?
[10:12] <asac> Ubulette: to figure out whats wrong your can prepare a source package and write to debian-mips@l.d.o
[10:23] <asac> tbird 1.5.0.13 is out ... ok ... back to interrupted workflow ;)
[10:42] <Ubulette> latest trunk broke some extensions
[10:42] <Ubulette> including TMP
[10:52] <Ubulette> see you
[10:57] <asac> TMP?
[11:16] <Jazzva> Morning :)...
[11:16] <asac> hi Jazzva
[11:16] <asac> Jazzva: already finished first exam?
[11:17] <Jazzva> asac: Yeah... I don't think I'll pass this one... though, that's what I expected, since I hadn't been studying it enough...
[11:17] <Jazzva> asac: And I'm not really into analog electronics :)
[11:17] <asac> yes ... thats probably painful :)
[11:18] <Jazzva> asac: A lot (but, I may be exaggerating :))... How are the stuff going in here, over there?
[11:19] <asac> Jazzva: we have bugs that complain that plugin finder service doesn't work on livecd
[11:19] <asac> haven't verified that yet
[11:19] <Jazzva> s/may\ be/am\ probably/
[11:19] <asac> on the other front i am preparing security updates for tbird 1.5.0.13 ... which was released today
[11:20] <Jazzva> asac: Really :(? Damn... I could check it out, though it would probably take half a day to download it, and would be able to do it tomorrow morning anyway...
[11:20] <Jazzva> s/morning/evening/
[11:21] <Jazzva> asac: BTW, I noticed that there is a beta of new Flash plugin... Are we gonna package that one?
[11:22] <Jazzva> (though, it didn't work well with youtube videos. It didn't react on click event.)
[11:25] <asac> usually we don't care for flash beta
[11:25] <asac> in a perfect world we wouldn't care for adobe flash at all ;)
[11:26] <asac> but unfortunately free-flash hasn't come that far yet
[11:26] <Jazzva> asac: Yeah *sighs*...
[11:26] <Jazzva> asac: So, no flash beta packaging? Ok :).
[01:06] <asac> Jazzva|away: you there?
[01:07] <jeromeg> hello all
[01:07] <jeromeg> asac : any news on the feed bug ?
[01:07] <asac> Jazzva|away: if you have a minute would be cool if you could try if the plugin finder service installs things for you
[01:07] <asac> jeromeg: yes
[01:08] <asac> jeromeg: its a bug :)
[01:08] <jeromeg> asac : really ;) ?
[01:08] <asac> i think i found why this is happening ... it's broken when don't have the gnome bits installed
[01:08] <asac> and because -gnome-support appears to be empty it doesn't work
[01:08] <jeromeg> ok
[01:08] <asac> so we have two bugs: first ... why the hell is this gnome dependent? that should be fixed for real
[01:09] <jeromeg> yes it's strange
[01:09] <asac> second: our packaging is broken as gnome-support package is empty and so nobody has the needed bits
[01:09] <asac> jeromeg: well i saw its really gnome dependent in code ... it needs coding
[01:10] <jeromeg> asac : but can't we keep to the upstream way of doing things ?
[01:10] <asac> jeromeg: namely, the shell-service we cannot resolve is a *GNOME* component ... we need to write a normal one
[01:10] <asac> no
[01:10] <jeromeg> ok
[01:10] <asac> we cannot force all gnome dependencies on all users
[01:10] <Jazzva|away> asac: Here now...
[01:11] <asac> Jazzva|away: there is the bug that it doesn't work on CD ... now it doesn't work in my install anymore
[01:11] <Jazzva|away> Should I pull your branch?
[01:11] <asac> when did that happen?
[01:11] <asac> i mean it worked
[01:11] <asac> the finder service appears to work well
[01:11] <asac> Jazzva|away: please try ubufox package first
[01:11] <asac> then if that doesn't work try the branch (e.g. produce .xpi and install that)
[01:11] <Jazzva|away> asac: ok... I'll do it now.
[01:12] <Jazzva|away> asac: Was there any change to gnome-app-install?
[01:12] <Jazzva|away> If you know...
[01:12] <asac> but install isn't working ...
[01:12] <Jazzva|away> If you don't I'll just look it up...
[01:12] <asac> no ... it looks like apturl is not invoked at all
[01:12] <Jazzva|away> Ok... I'll try it now...
[01:12] <asac> i see an error in error console which looks a bit like it might be the formatted string thing
[01:12] <asac> Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.formatStringFromName] "  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: XStringBundle :: getFormattedString :: line 33"  data: no] 
[01:12] <asac> Source File: XStringBundle
[01:12] <asac> Line: 33
[01:13] <Jazzva|away> I'll take a look...
[01:13] <asac> maybe the switch to use getFormattedString broke this and our QA failed?
[01:14] <asac> thanks
[01:14] <Jazzva|away> But if I remember correctly, I didn't use the getFormattedString... Though, I did change the getFormattedString to first lookup in local files for strings
[01:15] <asac> please try ... maybe you can track down the regression by going down the bzr revision
[01:15] <asac> s
[01:15] <Jazzva|away> Ok...
[01:15] <Jazzva|away> I'll see what I can find :)
[01:18] <asac> hmm ... LP has hick-ups again.
[01:23] <Jazzva|away> *sigh* I need to wait for update packages list in chroot... That's the place where I don't have to deinstall plugins :)
[01:39] <Jazzva> asac: Hmm... it says that ubufox is already the newest version :/...
[01:40] <Jazzva> Hmm... I don't remember updating in chroot, but it is already at -0ubuntu2
[01:44] <Jazzva> asac: (Maybe) unrelated question: do you use opendns?
[01:48] <gnomefreak> i guess we released the freeze?
[01:48] <asac> yep
[01:48] <asac> what do you want uploaded
[01:49] <asac> Jazzva: why maybe? ... i don't use opendns
[01:49] <gnomefreak> nothing atm, i just got 50 updates
[01:49] <asac> ah
[01:49] <asac> ;)
[01:49] <gnomefreak> thats why i guessed :)
[01:50] <gnomefreak> asac: btw iceape doesnt have a profile in ~/
[01:50] <gnomefreak> is this normal?
[01:50] <asac> yes
[01:50] <asac> its in .mozilla/
[01:50] <gnomefreak> not under name of iceape
[01:50] <asac> there should be a hmm suite/iceape/seamonkey folder?
[01:50] <Jazzva> asac: Well, because I use it and the window title for XStringBundle is "Source of: http://guide.opendns.com/?url=xstringbundle"... Never midn :)
[01:50] <gnomefreak> nope
[01:50] <asac> gnomefreak: probably its default
[01:51] <Jazzva> *mind
[01:51] <asac> Jazzva: have you checked stepping one revision back?
[01:51] <Jazzva> brb
[01:51] <Jazzva> Back...
[01:51] <asac> wow that was fast ;)
[01:52] <gnomefreak> hmmmm its seems it is default since i think thats the only chatzilla i have installed
[01:52] <Jazzva> Just reconnected to my network... Thought that maybe the connection with server will brake, but it didn't :)...
[01:53] <gnomefreak> brb this diet is gonna kill me one of these days
[01:53] <Jazzva> asac: What revision is the one revision back? :)
[01:54] <Jazzva> asac: Umm... how urgent is this check *unsure*? Would it be a problem if I check it tonight? ...around 9pm or something like that
[01:55] <asac> Jazzva: look at bzr log
[01:55] <asac> Jazzva: if i didn't do it by that then its fine ... obviously ;)
[01:56] <Jazzva> asac: Sorry... BTW, if you have something else to do, please do it :)... I would like to do this one...
[01:56] <Jazzva> asac: Something popped out over here, that I have to finish :/...
[01:57] <asac> sure ... problem is that i want a fix up asap ... but i have even more important things todo atm, so maybe you have luck :)
[01:57] <Jazzva> asac: Yaaay... :)
[01:57] <Jazzva> asac: I'll see you tonight then... Once again, sorry for this...
[02:02] <gnomefreak> asac: anything need to be looked at this morning? if not i think im gonna set a temp patch in sunbird to get rid of the updates option
[02:02] <asac> gnomefreak: which updates option?
[02:03] <gnomefreak> the one in the menu
[02:03] <gnomefreak> help>check for updates
[02:08] <gnomefreak> @schedule new_york
[02:08] <ubotu> Schedule for America/New_York: Current meeting: MOTU Team | 27 Aug 11:00: Screencast Team | 28 Aug 11:00: Ubuntu Server Team meeting | 28 Aug 15:00: Technical Board | 29 Aug 16:00: Edubuntu | 03 Sep 09:00: Community Council
[02:09] <gnomefreak> hnmmmm
[02:10] <gnomefreak> iceape is fucked :(
[02:10] <asac> wtf ;)
[02:10] <asac> ?
[02:10] <gnomefreak> i only get half a screen and half the menu items
[02:11] <asac> well ... thats apish ... at best ;)
[02:11] <asac> gnomefreak: your personal build or the super-official universe package?
[02:11] <gnomefreak> official
[02:11] <asac> borked profile?
[02:11] <gnomefreak> i just removed 3 .jar files
[02:12] <gnomefreak> they were the 3 extensions
[02:12] <asac> well that might break a lot ;)
[02:12] <asac> gnomefreak: have they been installed globally?
[02:12] <gnomefreak> how would removing flashgot.jar extensionmanager.jar and noscript.jar affect it this way
[02:12] <asac> e.g. as root?
[02:12] <gnomefreak> asac: no
[02:12] <asac> extensionmanager.jar?
[02:12] <asac> whats that?
[02:13] <gnomefreak> it is a broken extension manager
[02:13] <asac> gnomefreak: point is that iceape doesn't update its gnome registry by just removing the jars
[02:13] <asac> so iceape tries to load chrome files from those jars ... which fails ... and break things
[02:13] <gnomefreak> it makes installing ectensions easier and allows you to remove them
[02:13] <asac> where have they been installed ... those jars?
[02:14] <gnomefreak> they were in crome
[02:14] <gnomefreak> chrome
[02:14] <asac> what was the full path?
[02:14] <asac> if they have been in /usr/lib/iceape/chrome ... you should run update-iceape-chrome once
[02:15] <asac> otherwise you might wanna try to fix the chrome.rdf file in your profile by hand
[02:15] <asac> at best keep a backup of the profile :)
[02:15] <gnomefreak> ~/.mozilla/default/d3af2nu0.slt/chrome
[02:16] <asac> yeah try to fix chrome.rdf manually
[02:26] <asac> ok lunch now
[02:30] <gnomefreak> ok have fun
[03:03] <asac> re
[03:04] <jeromeg> re
[03:16] <gnomefreak> hmmmm it seems the patch for the pref. go button for iceape isnt applied
[03:23] <gnomefreak> who was it that was working on liferea
[03:24] <asac> gnomefreak: jeromeg?
[03:24] <jeromeg> yep ?
[03:24] <gnomefreak> no unless he took over for the other person
[03:25] <gnomefreak> jeromeg: are you working on liferea by chance?
[03:25] <asac> damn i think i really forgot
[03:25] <jeromeg> gnomefreak: depending what you mean by working :)
[03:25] <asac> probably looking at changelog might help
[03:25] <jeromeg> gnomefreak: you might want to have a look at the bug contact in LP
[03:25] <jeromeg> gnomefreak: there is one and it's not me
[03:26] <jeromeg> asac : btw I was reviewing some old bugs
[03:26] <jeromeg> and this seems to be fixed for me : bug 14576
[03:26] <ubotu> Launchpad bug 14576 in firefox "invalid certificate dialog blocks all future pages from loading" [Unknown,Fix released]  https://launchpad.net/bugs/14576
[03:26] <gnomefreak> was it sacater
[03:27] <asac> jeromeg: what did that bug claim (please summarize)
[03:27] <asac> gnomefreak: no
[03:28] <asac> gnomefreak: slomo
[03:28] <jeromeg> gnomefreak: two bug contcts : Emilio Pozuelo Monfort
[03:28] <jeromeg> and
[03:28] <jeromeg> Sebastian Drge
[03:28] <gnomefreak> it was emilio than
[03:28] <asac> yeah pochu and slomo
[03:28] <asac> i think both
[03:29] <gnomefreak> k i havent seen either around lately
[03:29] <gnomefreak> hmmmm
[03:29] <asac> gnomefreak: wasn't it you who wasn't around ;)
[03:29] <gnomefreak> :)
[03:29] <asac> just in case you forgot that your perception might be prolonged by that fact :)
[03:30] <jeromeg> asac : when you didn't confirm/reject and invalid certificate it would prevent other pages to be opened in FF until you confirm/reject it
[03:30] <asac> ah
[03:30] <asac> ok that is really gone?
[03:30] <jeromeg> I can't reproduce it on my Xubuntu Feisty box
[03:31] <jeromeg> it only blocks the window where the certificate is
[03:31] <jeromeg> and you can open other pages
[03:31] <asac> ok close it fix released and say that it appears to be fixed in 2.0.0.x
[03:31] <jeromeg> and browse
[03:31] <asac> jeromeg: fine
[03:31] <jeromeg> ok
[03:31] <asac> tell reporter he might open if he still sees this in 2.0.0.5
[03:31] <asac> aeh .6
[03:32] <jeromeg> asac : done
[03:48] <asac> tx
[03:57] <gnomefreak> im out for a bit have to get food shopping and shit done before weekend
[05:24] <cwong1> asac: good afternoon
[05:27] <asac_the_2n1> welcome back cwong1 ;)
[05:27] <asac_the_2n1> hope you had a nice holiday
[05:28] <cwong1> asac_the_2n1: did have a nice vacation but hurt myself from hiking...
[05:28] <asac_the_2n1> ouch
[05:28] <asac_the_2n1> can you still move?
[05:28] <cwong1> asac_the_2n1: yea
[05:29] <cwong1> anyway I talked to bob and we agreed on getting the menu hildonize first and then the top level window later
[05:29] <cwong1> Will you have time to work on this in the next week or so?
[05:29] <asac_the_2n1> yep ... thats what i know as well
[05:30] <asac_the_2n1> cwong1: the tree builds a native midbrowsercomps shared library which for now contains the hildoneservice
[05:30] <asac_the_2n1> ... which currently does nothing, but should follow soon
[05:30] <cwong1> is it already checked-in to the WORKING?
[05:30] <asac_the_2n1> yes
[05:31] <asac_the_2n1> someone should start to do the new menu xul ... and even add the xbl that makes out of menubar just a normal popup for now
[05:31] <asac_the_2n1> hopefully you can :)
[05:31] <cwong1> great,  I will re-layout the menus and look into themeing next week
[05:32] <asac_the_2n1> cwong1: cool ... afaik kwwii is into theming, but it wouldn't hurt if you can provide the technical basis
[05:32] <asac_the_2n1> as he is not a programmer
[05:32] <cwong1> kwwii is a user, right?
[05:33] <asac_the_2n1> no he is our (canonical) artist
[05:33] <cwong1> oh, I think I met him at Google..
[05:33] <asac_the_2n1> i think he does the hildon theme ... but he hasn't really started from what i understood when i asked him on #ubuntu-mobile
[05:34] <asac_the_2n1> for its its just important that the theming can be done (hopefully just by copying a gtkrc rule)
[05:34] <asac_the_2n1> and maybe take a glance at how it looks like :)
[05:34] <cwong1> Will you be able to spend time working on hooking up the xevent in hildon in the next 2 weeks?
[05:34] <asac_the_2n1> i plan to do another bunch today
[05:34] <cwong1> I will chat with kwii and bob
[05:34] <cwong1> great
[05:35] <cwong1> today we are going thru the schedule
[05:35] <asac_the_2n1> from what i saw it is even simpler ... only thing is to recognize which menu is in current top window
[05:35] <asac_the_2n1> but judging from hildon code i looked at this isn't a big problem either
[05:35] <asac_the_2n1> we can just copy the way they do it (i hope)
[05:35] <cwong1> cool
[05:36] <asac_the_2n1> there is a nsHildonXEventService.idl in new tree
[05:36] <cwong1> also, if you question I can provide you a contact to nokia
[05:36] <cwong1> ok
[05:36] <asac_the_2n1> basically the overlayed menubar will just register itself as listener and then will receive hide/show events
[05:36] <cwong1> ok
[05:36] <asac_the_2n1> cwong1: is nokia contact online? or just through mail?
[05:37] <cwong1> yes he is on ubuntu-mobile most of the time
[05:37] <cwong1> asac_the_2n1: I will ask bob for his username and email and sent to you some time today
[05:37] <asac_the_2n1> ok thanks
[05:38] <cwong1> asac_the_2n1: I have a question reguarding add-ons
[05:38] <asac_the_2n1> sure
[05:38] <cwong1> asac_the_2n1: I was having problem install add-on with midbrowser.  I think it has to do with version.
[05:38] <cwong1> right?
[05:38] <asac_the_2n1> we have a distinct app-id
[05:39] <asac_the_2n1> so you won't be able to install firefox addons ... which is sane as most hooks they use will probably not exist
[05:39] <asac_the_2n1> however for some extensions it might work ... like addblock et al
[05:39] <asac_the_2n1> those we just need to check that they work and tell author to add our app-id to compability list
[05:39] <asac_the_2n1> or provide them on our own
[05:39] <cwong1> Is that a way to work around this?
[05:40] <asac_the_2n1> not unless you want to use official firefox app-id ... but that is not really a solution.
[05:40] <asac_the_2n1> the app-id exists to identify if an extension will work
[05:40] <asac_the_2n1> and we cannot say that we work with all firefox extensions
[05:41] <cwong1> I thouhgt in the previous version 2.0.04 it only looks at the version number
[05:41] <asac_the_2n1> yes ... but that was just because we didn't yet have our own application
[05:41] <cwong1> that might be a problem.  In our PRD, we says we supports existing addons.
[05:42] <cwong1> our own application?
[05:42] <asac_the_2n1> ... which is impossible (and whatever you do it wouldn't be possible) ... on a broad base ... moblin.org should setup their own addons site ... and import/synch those addons that work
[05:43] <asac_the_2n1> cwong1: addons heavily rely on UI elements that exist
[05:43] <asac_the_2n1> and since we don't have all ui elements that firefox has, lots of extensions would break
[05:43] <asac_the_2n1> so yes ... we have our own application called "midbrowser"
[05:43] <cwong1> like existing thems...
[05:44] <asac_the_2n1> cwong1: its rather simplish to maintain a list of tested themes extensions and auto import them ... adding our app-id to install.rdf
[05:44] <asac_the_2n1> its definitly worth the efford
[05:44] <asac_the_2n1> but allowing users to install every firefox extension without us reviewing/testing it first would contribute bad to user-experience
[05:45] <cwong1> hmmm... I will have to discuss this with bob.  This will definitely add more times to our schedule..
[05:46] <cwong1> thanks for the info
[05:46] <asac_the_2n1> ... and i am pretty sure that bob knows about this ... what we have is a working extension mechanism with the likelyhood that we can reuse a good bunch of existing extensions .... hopefully we will get enough momentum to build up our own extension community then
[05:47] <cwong1> ok  I have to attend a meeting,  Will catch up with you later...
[05:47] <asac_the_2n1> cwong1: yes options are: 1. setup something to easily any extension we QAed to work with midbrowser ... 2. just provide a few (most important ones) that we know that they work. 3. not sure
[05:47] <asac_the_2n1> note that we could do 2. for the beginning and then improve our service to get 1 later
[05:47] <asac_the_2n1> yes cu
[05:48] <cwong1> ok.  I have a list here and will go thru them and see which one works.
[05:48] <cwong1> cu
[05:48] <asac_the_2n1> cwong1: yes... just add our app-id to install.rdf
[05:48] <asac_the_2n1> (to test)
[05:49] <cwong1> thanks
[05:49] <asac_the_2n1> the app-id is in nsMidbrowserApp.cpp
[05:49] <cwong1> ok
[07:15] <_Ubulette> hi
[07:16] <Ubulette_> whatever
[07:16] <Ubulette_> damn xchat
[08:09] <asac> hi Ubulette_
[08:20] <asac> hi Ubulette
[08:20] <asac> :)
[08:20] <Ubulette> hi
[08:20] <Ubulette> fighting with my sound..
[08:20] <asac> yeah ... looks like :)
[08:20] <asac> and with your nick ;)
[08:20] <Ubulette> gutsy killed it
[08:20] <asac> oh no
[08:20] <asac> don't scare me
[08:20] <asac> just wanted to upgrade my production system :)
[08:20] <Ubulette> new kernel
[08:21] <asac> the latest revision broke it?
[08:21] <asac> interesting
[08:21] <Ubulette> alsa and the last kernel don't match some audio card
[08:21] <Ubulette> s
[08:21] <asac> didn't knoiw that there was anything signifcant new in it
[08:21] <Ubulette>   * ubuntu: Disable snd-hda-intel, in favor of lum updated version
[08:21] <asac> ah ... yeah use the lum one then :-D
[08:21] <Ubulette> so it's not really a bug
[08:22] <asac> hmm ... transitions should rock in ubuntu
[08:24] <Ubulette> well, as I cant use the previous kernel without trashing X (nvidia powaaaa), i have to recompile alsa k module
[08:25] <Ubulette> module-assistant is quite nice to make that easy
[08:27] <Ubulette> asac: here is what xulrunner trunk installed: http://pastebin.mozilla.org/188898
[08:28] <asac> Ubulette: are the /usr/lib/xulrunner-devel-1.9a8pre/sdk/lib/ *.so files the same as in pkglibdir?
[08:28] <asac> or even links?
[08:28] <Ubulette> in fact, all moz apps are like that. we dropped the versionning in gp/trunk
[08:29] <asac> ok ... makes sense
[08:29] <asac> what about package-config files
[08:29] <asac> do they work well?
[08:30] <asac> are stable and unstable symbols (as sorted in include) represented by their own libs?
[08:30] <asac> or is it a mixup?
[08:30] <asac> Ubulette: ... and please post the content of    7.
[08:30] <asac>       /etc/gre.d/1.9a8pre.system.conf
[08:30] <asac> ups
[08:30] <asac> yeah ... of that file
[08:31] <Ubulette> http://pastebin.mozilla.org/188899
[08:31] <asac> thanks
[08:32] <asac> and the gre.d ?
[08:33] <Ubulette> [1.9a8pre] 
[08:33] <Ubulette> GRE_PATH=/usr/lib/xulrunner-1.9a8pre
[08:34] <Ubulette> that makes sense
[08:34] <asac> cannot remember for sure what they did for 1.8
[08:34] <Ubulette> that's go for 1.9.0.0
[08:34] <asac> sure?
[08:35] <Ubulette> as they did /usr/lib/xulrunner-1.8.1.3
[08:35] <asac> yeah ... that sucks for real then
[08:35] <Ubulette> we can drop the last digit for sure
[08:35] <Ubulette> maybe the 3rd too
[08:35] <Ubulette> but not the first two
[08:35] <asac> just the last
[08:36] <asac> but that is not given of course
[08:36] <asac> i think we should handle it like as if we track ABI/API
[08:36] <Ubulette> that would already be an improvement for us
[08:36] <asac> if we see breakage we bump the last digit
[08:37] <asac> otherwise we keep it unmodified
[08:37] <Ubulette> like ship libxul1.9.0-dev-1.9a8pre
[08:37] <asac> e.g. we get to know in 1.9.0.8 they broke something ... we use xulrunner-1.9.0.8 afterwards ... before we stay 1.9.0.0
[08:38] <Ubulette> and later libxul1.9.0-dev-1.9.0.1
[08:38] <Ubulette> etc. lile gstreamer
[08:38] <Ubulette> like
[08:38] <asac> and what if the above case comes?
[08:38] <Ubulette> i meant libxul1.9.0-dev-1.9~a8pre
[08:39] <asac> as source package version?
[08:39] <asac> or is that a debian revision in the back?
[08:39] <asac> -1.9~a8pre
[08:39] <asac> ??
[08:40] <Ubulette> I mean, prepending 2 or 3 digits to all package names so we can install several for differents apps
[08:40] <Ubulette> look at gstreamer
[08:40] <asac> though gstreamer represents two branches
[08:40] <asac> 0.8 and 0.10
[08:40] <Ubulette> there are tons of gstreamer0.8-* and tons of gstreamer0.10*
[08:40] <asac> while 1.9.0.x is one branch
[08:41] <asac> that is solely security/stability maintenance ... but with the chance that abi/api breaks
[08:41] <Ubulette> we could have 1.8.1, 1.9.0, 1.9.1 or just 1.8, 1.9
[08:41] <asac> especially for the unstable parts
[08:41] <asac> but what
[08:41] <asac> 20:37 < asac> e.g. we get to know in 1.9.0.8 they broke something ... we use xulrunner-1.9.0.8 afterwards ... before we stay 1.9.0.0
[08:41] <asac> ?
[08:42] <asac> what in case 1.9.0.8 breaks compatibility
[08:42] <Ubulette> should not, according to their propaganda
[08:42] <Ubulette> it should be 1.9.1.0 then
[08:42] <asac> well .. i am not sure where you read that ... but from what i know they don't have an official policy for that
[08:43] <Ubulette> last digit is security fix or last minute fix
[08:43] <asac> they say according to benjamin you should link to static stub ... and that will find a suitable gre for you
[08:43] <asac> Ubulette: yes, but there is no policy that security fix doesn't break unstable api elements
[08:43] <asac> they will deliberately do it when it becomes obvious that its too difficult to do otherwise
[08:44] <asac> if they had such a policy, they would probably install to xulrunner-1.9.0 on their own
[08:44] <asac> but they say that thy don't care a bit that you have to respin applications
[08:45] <asac> and that you should better use the static xpcom stub
[08:45] <asac> then using shared libs
[08:45] <asac> as that is the ultimate solution et al
[08:45] <asac> (all this stupid things)
[08:46] <asac> Ubulette: http://benjamin.smedbergs.us/blog/2006-02-22/debian-versioning-of-mozilla-libraries-harmful/
[08:46] <asac> read just the section "the proven solution"
[08:46] <Ubulette> glue(_s).a is good but it means many installed xul at the same time
[08:47] <asac> Ubulette: no he really means it useful as an upgrade path
[08:47] <asac> so you won't have to recompile even though you roll out /usr/lib/xulrunner-1.8.0.6
[08:48] <Ubulette> he?
[08:48] <asac> he? :)
[08:48] <Ubulette> eh
[08:48] <Ubulette> eeeehhhh?
[08:48] <asac> e.g. you link statically against glue from 1.8.0.4
[08:49] <asac> then you start ... and the glue loads 1.8.0.6 .. because it figures out its compatible
[08:49] <asac> thats how i understand what he writes
[08:49] <asac> otherwise it doesn't make sense at al ... and i suppose he is not completely unreasonable
[08:55] <asac> Ubulette: iirc they maintain compatibility hints somewhere ... but i might have dreamed that
[08:55] <asac> Ubulette: if that magic glue autodetects best?? xulrunner works, we can just ship it as is
[08:55] <asac> maybe we should try and see what happends when a9 is out :)
[08:56] <Ubulette> a8
[08:56] <asac> whatever :)
[08:56] <asac> a9 will be the first upsream bump (or beta)
[08:56] <asac> if its a bump for them at all
[08:56] <Ubulette> so how do we name packages ?
[08:57] <asac> for now just stuff everything in xulrunner-1.9 and xulrunner-devel-1.9
[08:57] <asac> as that appears to be the way that want it
[08:57] <asac> e.g. name it like they name the pkglibdir
[08:57] <asac> what version to append depends on what we want to be allowed in parallel
[08:58] <asac> maybe use 1.9.0
[08:58] <Ubulette> I would tend to go for foo1.9, libfoo1.9, libfoo1.9-dev, foo1.9-dev foo1.9-gdb, etc
[08:58] <asac> no we don't ship it as a lib
[08:58] <asac> as its not a lib in that sense
[08:58] <asac> its a runner and an sdk
[08:58] <asac> everything else gives false impressions
[08:59] <Ubulette> yeah, u're right
[08:59] <asac> wait a sec
[08:59] <asac> there is a vision from the same guy how to package it :)
[09:00] <asac> do you have the master make install bug id?
[09:01] <Ubulette> mozilla bug 386904
[09:01] <ubotu> Mozilla bug 386904 in Build Config "DIST_FILES and DIST_CHROME_FILES not implemented for install:: target in config/rules.mk" [Normal,Assigned]  http://bugzilla.mozilla.org/show_bug.cgi?id=386904
[09:02] <asac> Ubulette: http://benjamin.smedbergs.us/blog/2006-03-27/building-the-xulrunner-sdk/
[09:02] <asac> I would like some feedback on this proposal, especially as it affects RPM packages and Linux distributions. My current idea for RPM structures would look like this:
[09:02] <asac>     * XULRunner-1.9 RPM
[09:02] <asac>       ships the contents of dist/bin to /usr/lib/xulrunner-1.9
[09:02] <asac>     * XULRunner-dev-1.9 RPM
[09:02] <asac>       depends on XULRunner-1.9
[09:02] <asac>       ships the contents of dist to /usr/lib/xulrunner-1.9-dev
[09:02] <asac>       /usr/lib/xulrunner-1.9-dev/bin is a symlink to /usr/lib/xulrunner-1.9 (to avoid having to ship two copies of the XULRunner runtime)
[09:03] <asac> i think we should just adapt that and see how far we get ...
[09:04] <asac> and each package shipts its own /etc/gre.d info file
[09:04] <asac> then we have to review debian packages and take care that they don't link against shared-libs directly
[09:04] <asac> but use static glue
[09:04] <asac> which can be quite some work
[09:04] <asac> and will probably reveal a bunch of problem
[09:04] <asac> s
[09:05] <asac> but i think epiphany should be prepared for that
[09:05] <asac> as it builds on redhat and redhat packages like mozilla wants already
[09:06] <asac> furthermore ... would be interesting to see how well their own xul application firefox-gp can handle to just link to static glue
[09:06] <asac> if it doesn't we should really talk to this guy ;)
[09:07] <asac> anyway ... i think libnspr and libnss can stay as they are ... as they are real libs ... and you can build xulrunner against system-XXX
[09:07] <asac> and the soname versioning allow automatic shlibs depends detection ... which is fine as well
[09:10] <Ubulette> ok, i'll start experimenting once i've quiltified xulrunner 1.8
[09:10] <Ubulette> still no sound, I'm getting nervous...
[09:11] <asac> oh :)
[09:11] <asac> why do you quiltify xulrunner?
[09:11] <asac> the package will be completely different
[09:11] <asac> better start from scratch
[09:11] <asac> it should be really trivial to package if we just stick to upstream
[09:11] <asac> just cdbs with nothing else
[09:11] <asac> and quilt to add patches that we need now
[09:12] <asac> mike will never accept to adapt the packaging that we try ... so there is no benefit to stick to the way he likes
[09:12] <asac> just do it how you like it
[09:12] <Ubulette> then i can trash my branch and start from scratch
[09:12] <asac> well ... maybe keep it in case we get to know that packaging the upstream way won't get us anywhere
[09:12] <asac> (which i don't hope)
[09:13] <asac> Ubulette: and maybe mike wants your quiltification for 1.8 ... if you already started
[09:15] <Ubulette> not yet, i've just imported his xulr as it was
[09:16] <asac> ah ... ok
[09:16] <Ubulette> not much time that week
[09:16] <asac> thats fine ;) .... actually i am a bit unsure what bsmedberg wants ... he installs with 4 digit versioning ... but in his widget he just ships two digits
[09:17] <asac> i think we want 3 digits ;)
[09:17] <asac> and i think thats what he wants as well
[09:17] <Ubulette> me too
[09:17] <asac> at least in the package name
[09:17] <asac> the pkglibdir might be 4 digits
[09:17] <asac> we have to test if the glue is really that samrt
[09:17] <Ubulette> let's hope it is
[09:17] <asac> e.g. that it picks up the most recent that is compatible
[09:17] <asac> maybe look in code :)
[09:18] <asac> shouldn't be too hard
[09:18] <asac> i can do that later
[09:18] <asac> today maybe
[09:18] <Ubulette> 1st thing 1st, reboot to see if my new alsa worked
[09:18] <asac> if pkglibdir is 4 digites we can also ship plain 1.9 with two digit in package name and in case there is a 1.9.1 series just expand the package name to 3 digits
[09:19] <asac> Ubulette: is the xulrunner upstream orig available on your server?
[09:20] <Ubulette> it is
[09:20] <Ubulette> a few days old
[09:20] <Ubulette> brb
[09:21] <Admiral_Chicago> does someone know how I can fix this http://img250.imageshack.us/img250/7553/problemoa2.png
[09:23] <Admiral_Chicago> this happens when I try to launch the browser
[09:24] <Ubulette> good. fixed :)
[09:28] <asac> Admiral_Chicago: where does that happen?
[09:28] <asac> do you use trunk?
[09:29] <asac> or on stable ffox?
[09:31] <asac> bug 119038
[09:31] <ubotu> Launchpad bug 119038 in enigmail "MASTER Key management / Recipient Key Selection broken (endless loop in EnigConvertToUnicode)" [Undecided,Fix committed]  https://launchpad.net/bugs/119038
[09:34] <Admiral_Chicago> asac: when i use stable, when i'm launching firefox
[09:35] <Admiral_Chicago> launching from the console just says "Segmentation fault (core dumped)"
[09:43] <asac> what did you do?
[09:43] <asac> since when do you get that?
[09:44] <asac> Admiral_Chicago: have you replaced libnss/libnspr with ubulettes version?
[09:50] <Admiral_Chicago> no, was i supposed to
[09:50] <Admiral_Chicago> i think it was when i was moving profile
[09:50] <Admiral_Chicago> profiles*
[10:16] <Ubulette> asac, gnomefreak, trunk 3.0a8pre+cvs20070824t1108 is in my repo if you're interested
[10:20] <Ubulette> asac, what about the -trunk name in nspr/nss ? I think it's useless (only in source, not in debs)
[10:27] <asac> thats good to have
[10:27] <asac> so we can have both in one archive ;)
[10:27] <asac> Ubulette: we already taked about that before?
[10:28] <Ubulette> dont remember the details
[10:29] <asac> different source package + name bin package gives us options ... like testing the transition we will do at some point et al
[10:29] <asac> s7
[10:29] <asac> s/name bin package/same name for bin packages/
[10:30] <Ubulette> but xul control file will not show that "trun" thing, no way
[10:30] <Ubulette> k
[10:30] <asac> huh?
[10:30] <asac> what do you mean?
[10:31] <asac> xul doesn't build nspr/nss ... but uses our system libs ... did you ask that?
[10:33] <Ubulette> so it will just be nss >= x ?
[10:33] <asac> right
[10:33] <asac> actually it should automatically detect the bin depends
[10:33] <asac> but for -dev package its true ... yes.
[10:34] <Ubulette> hm, ok
[10:34] <asac> maybe you have to generate the appropriate lower build in nss-trunk package ... like its done in current stable packages
[10:35] <asac> s/lower build in/lower version constraint during build of/
[10:35] <asac> damn ... i should better go to bed
[10:35] <asac> ;)
[10:35] <asac> cannot phrase any basic sentences
[10:36] <Ubulette> i'm tired too. I should start that tomorrow
[10:36] <Ubulette> yep, that's best
[10:37] <asac> ok ... then night ;) ... cu tomorrow!
[10:42] <gnomefreak> :( i have to fix nss nspr now ill be around for a bit
[10:44] <asac> gnomefreak: why?
[10:44] <asac> isn't everything allright?
[10:44] <gnomefreak> FTBFS
[10:44] <asac> for you?
[10:44] <gnomefreak> for PPA
[10:44] <asac> ah
[10:44] <asac> ok
[10:44] <gnomefreak> where is his nss and nspr branches?
[10:45] <asac> ~fta
[10:45] <asac> ??
[10:45] <asac> there you should find
[10:45] <gnomefreak> ty found i think
[10:45] <Ubulette> i'm still there (just not doing xul thing)
[10:46] <Ubulette> what's broken ?
[10:46] <gnomefreak> Ubulette: it was something i did
[10:47] <gnomefreak> i think
[10:47] <gnomefreak> since its only mt2 that fails
[10:48] <Ubulette> would be nice to bzr those new files
[10:48] <asac> NEW files?
[10:49] <gnomefreak> when i get it done and it builds ill set up branch so you can merge the changes if that is what you mean
[10:49] <Ubulette> well, I don't know what you had to change for those two ppa attempts
[10:50] <asac> probably just changelog
[10:50] <Ubulette> I guess ppa is at least one new file
[10:50] <gnomefreak> changelog and control
[10:50] <asac> new==updated or new=added?
[10:50] <asac> gnomefreak: why control?
[10:50] <asac> ah right
[10:51] <asac> Section thing
[10:51] <gnomefreak> thats wher eyou change libs to universe/libs
[10:51] <asac> what happens if you don't?
[10:51] <Ubulette> goes in main
[10:51] <asac> e.g. just use libs (unmodified)
[10:51] <asac> yeah ... but what is main for ppa?
[10:51] <gnomefreak> cant have to use universe/libs
[10:52] <asac> so how does the apt line look for our ppa?
[10:52] <asac> do we have main and universe there as well?
[10:52] <gnomefreak> yes
[10:53] <asac> ok
[10:53] <asac> i somehow don't understand why they did that split
[10:53] <asac> probably only to reduce possible build-depends ... so you can test in a more *real* enviornemnt
[10:54] <gnomefreak> main shouldnt have been in there at this point but since i left binaries section alone it put bins in main and source in universe
[10:54] <asac> ok
[10:58] <Jazzva> Evening...
[10:58] <Jazzva> asac, you there?
[11:00] <asac> well not really
[11:00] <asac> whats up?
[11:01] <Jazzva> asac: Well, finished everything that I had and am going to take a look at ubufox now...
[11:01] <asac> great
[11:01] <asac> i didn't do it so far
[11:01] <asac> help appreciated
[11:02] <Jazzva> asac: Ok, I'll see what I can do now... Sorry for just leaving like that earlier...
[11:02] <Ubulette> guys, could you document how to use the mt ppa ?
[11:02] <asac> no need to be sorry
[11:03] <asac> Ubulette: which perspective? user or developer?
[11:03] <Ubulette> dev
[11:03] <asac> technically or policy?
[11:03] <Ubulette> tech
[11:03] <asac> what info do you need?
[11:03] <asac> how to upload?
[11:03] <Jazzva> asac: On the other side, the reply from fakenes' upstream about cbuild relicensing came and it's not really good :/.. They can't relicense the build system, as it's not their, and stuff... I can forward you the mail. I don't think it will be any close to free for gutsy.
[11:04] <asac> Jazzva: well ... the idea was not to relicense, but to use a different build system
[11:04] <asac> they should go away from that evil thing
[11:04] <Ubulette> i don't even know what and where.. dput, debuild ?
[11:04] <Jazzva> asac: Yeah, she mentiond that's not possible too... :/
[11:04] <asac> Ubulette: ah ... ok we can document that
[11:05] <Jazzva> asac: Not possible at the moment, that is...
[11:05] <asac> Ubulette: its basically source-only uploads (so -S -sa on first orig.tar.gz ... then -S -si)
[11:05] <asac> you have to specify the right distribution in changelog
[11:05] <asac> then dput or dupload to ppa
[11:05] <asac> i will bug gnomefreak to post his dput.cf entry as an example
[11:06] <asac> Ubulette: you need a gpg key in launchpad i guess
[11:06] <Ubulette> already there
[11:06] <asac> Ubulette: please don't use a zero-password one
[11:06] <Ubulette> oh
[11:06] <asac> then using that key should be enough
[11:06] <Ubulette> why not a no password key ?
[11:07] <asac> you can use gpg-agent i guess ... if you hate to type a password
[11:07] <asac> well ... its obvious isn't it?
[11:07] <asac> you might loose your key ... we might not notice ... upload goes in pest goes in
[11:07] <Ubulette> you think you can get my priv key ??
[11:07] <Ubulette> :)
[11:07] <asac> well ... it might happen
[11:07] <wojtekka> asac: hi, can i bother you again with network-manager bug 101857?
[11:08] <ubotu> Launchpad bug 101857 in network-manager "WPA doesn't work with NetworkManager using the bcm43xx driver (works with wpa_supplicant)" [Unknown,Confirmed]  https://launchpad.net/bugs/101857
[11:08] <asac> wojtekka: i have it running here
[11:08] <asac> wojtekka: it works perfectly
[11:08] <Jazzva> Ubulette: Take a look at this, there's an example of dput.cf there https://help.launchpad.net/PPAQuickStart
[11:08] <asac> wojtekka: try to get new firmware
[11:08] <Jazzva> Ubulette: And a quick guide how to configure it :)
[11:08] <wojtekka> asac: on a PPC?
[11:08] <asac> wojtekka: i am currently doing a testrun ... my laptop with bcm43xx showed 24G over the internet
[11:08] <asac> the last few days
[11:09] <asac> without any hick-ups
[11:09] <asac> wojtekka: no ... not ppc
[11:09] <asac> ppc not supported ... you know ;)
[11:09] <asac> can you use fwcutter on ppc at all?
[11:09] <asac> or is it something different?
[11:09] <Ubulette> oh.. you need to be an ubuntero to use a ppa
[11:09] <wojtekka> asac: so maybe that's why it works for you. it's just endianness issue in libnm.
[11:10] <wojtekka> asac: fwcutter works fine. in fact everything works fine except WPA.
[11:10] <asac> wojtekka: if you are so sure, please retitle the bug
[11:10] <asac> to reflect the endianess issue
[11:10] <asac> and at best track down the code that doesn't deal well with endianess
[11:10] <asac> btw, is endianess really different on ppc ?
[11:10] <asac> vs. x86?
[11:11] <wojtekka> asac: PPC is big-endian, so yes, it's different.
[11:11] <asac> k
[11:11] <asac> then change the bug title if you are sure
[11:11] <asac> and drop the place where endianess has to be dealt with
[11:11] <asac> i can then see if i can come up with a patch
[11:14] <wojtekka> asac: i have patches for feisty and gutsy already. the only problem is that i've messed something up with my system and NM connects only sometimes to WPA network (as opposed to _never_ connects without the patches).
[11:15] <asac> wojtekka: have you asked upstream to verify the patches?
[11:15] <wojtekka> asac: but as these patches are very simple and i've dealt with endianness issues in the past, i believe that they are correct. is there anythink like sid in Ubuntu? someplace where packages are uploaded to be tested before going to gutsy repos?
[11:15] <asac> they probably want them as well
[11:15] <asac> no ... there is no such place
[11:16] <asac> but we can try it
[11:16] <asac> i know other people with ppc who could verify ... and if nm gets worse for them we can always revert it
[11:17] <gnomefreak> damnit here we go again :(
[11:18] <wojtekka> asac: NM 0.6.4 didn't support big-endian systems at all, so Ubuntu package includes a patch. NM 0.6.5 pretends to support big-endian, but config.h with all defines from configure isn't included in the only file that is endian-dependent.
[11:19] <wojtekka> asac: anyway, I can attach patches to the bugreport and send them upstream for review.
[11:19] <asac> wojtekka: so 0.6.5 patch is rather trivial?
[11:20] <asac> wojtekka: please don't attach 0.6.4 we will not update it
[11:20] <asac> we live for the future
[11:20] <asac> wojtekka: or is the 0.6.4 patch now trivial (given that there already is a patch that tries to achieve that) ?
[11:21] <wojtekka> asac: both patches are trivial and non-intrusive for little-endian systems.
[11:21] <asac> ok well attach both ... let me look
[11:21] <wojtekka> asac: for 0.6.4 we need to add "#undef WORDS_BIGENDIAN" to config.h.in, for 0.6.4 and 0.6.5 it's simple #include "config.h" in one file.
[11:21] <asac> and try to submit 0.6.5 patch upstream
[11:22] <asac> they are still maintaining the  0.6 branch though they are pushing for 0.7
[11:24] <gnomefreak> asac: the emails im getting on iceape that was fixed upstream was that in 1.1.4 or will be fixed in 1.1.5
[11:24] <asac> no idea which ones you refer to
[11:24] <asac> emails on debian maintainers list?
[11:25] <gnomefreak> yes
[11:25] <asac> from when?
[11:25] <asac> today?
[11:25] <gnomefreak> i think sunbject was add-on
[11:25] <gnomefreak> asac: yes today
[11:25] <gnomefreak> i think it was dejavu fonts crash
[11:25] <asac> well ... fixed-upstream usually means that its fixed upstream and not yet in debian ... so given that 1.1.4 is in debian it probably isn't fixed in it
[11:26] <asac> otherwise it can mean anything ... from fixed in 1.1.5 ... to fixed on trunk
[11:26] <asac> yeah that one i don't understand as well
[11:26] <asac> oh well i understand
[11:26] <gnomefreak> k
[11:26] <asac> upstream fixed that iceape doesn't crash when the symlink is dangling
[11:26] <asac> ... while the real issue ... the dangling symlink has not yet been tracked down
[11:27] <gnomefreak> ah ok
[11:27] <asac> gnomefreak: do you use a passphrase for you gpg key?
[11:28] <gnomefreak> yes
[11:28] <asac> fine
[11:28] <asac> hopefully at least 16 characters ;)
[11:28] <asac> hehe
[11:28] <gnomefreak> nope
[11:32] <Jazzva> Konqueror is fun... I tried to open one website (deezer.com...) in it, so I can test ubufox in Firefox... and konqueror freezed...
[11:33] <asac> Jazzva: could you track down the checkin that caused the issue?
[11:33] <Jazzva> Well, I'm currently at 29th revision... testing it now :/
[11:33] <asac> what is the topmost?
[11:33] <Jazzva> 39
[11:34] <asac> ah maybe its simpler to unapply the ones that might have caused this by patching reversed
[11:34] <Jazzva> Though I'm skipping the even ones... when I find the odd, then I'
[11:34] <Jazzva> *I'll test the odd+1
[11:34] <asac> e.g. bzr diff -r 28..29 | patch -p0 -R
[11:34] <Jazzva> *the odd one that works
[11:34] <asac> did 28 still work?
[11:34] <Jazzva> I'll see that in the next test :)
[11:35] <Jazzva> I'm just not sure how we missed this
[11:35] <Jazzva> It worked nice, as in it run apt-get...
[11:36] <asac> well ... its always the same ... at some point you take things for granted that you shouldn't
[11:37] <Jazzva> lol
[11:37] <Jazzva> Well, in rev 29 it's not running g-a-i, but that was the point where I was working on getFormattedString :/...
[11:37] <Jazzva> I'll see if rev 30 works
[11:37] <asac> no try 28
[11:37] <asac> try the last revision that works
[11:38] <asac> find the last ... i mean
[11:38] <Jazzva> Ok... trying #28
[11:38] <asac> actually imo you should just try to fix getformattedstring
[11:38] <asac> e.g. by returning static string
[11:38] <asac> and see if it goes away
[11:38] <asac> as we already have an idea
[11:38] <asac> this revision downtracking is more useful if you have no idea at all
[11:38] <Jazzva> Ok... Just to try rev 28... :)
[11:38] <asac> sure
[11:42] <gnomefreak> ok cool nss is building :)
[11:43] <Jazzva> Ok... 28 works
[11:43] <Jazzva> There's probably no change in getFormattedString here :)
[11:44] <asac> yeah so patch 29 is the intruder
[11:44] <asac> how does the checkin look like?
[11:44] <asac> (please show that diff)
[11:44] <Jazzva> Probably... and maybe rev 30
[11:44] <asac> ok ... i think just fix that method and commit on top
[11:44] <asac> then
[11:44] <asac> try first by returning static string to see that its really the problem
[11:44] <asac> if that works find real solution
[11:45] <Jazzva> Ok
[11:46] <Jazzva> Off for a smoke, brb...
[11:52] <wojtekka> asac: okay, done. patches with description sent to launchpad and bugs.gnome.org. are you monitoring gnome bugs or do you want me to let you know when NM guys will have reviewed the patch for 0.6.5?
[11:54] <Jazzva> asac: Tested, works with static string... I'll try to find out what's the error... right after the smoke I  still have not started :).
[12:06] <asac> wojtekka: can you cc me to gnome bug?
[12:06] <asac> asac@jwsdot.com
[12:06] <asac> should be a valid email
[12:13] <gnomefreak> ok nss and nspr are fixed both built in PPA without issues
[12:16] <Ubulette> nice
[12:18] <wojtekka> asac: done.
[12:20] <asac> wojtekka: thanks
[12:25] <wojtekka> asac: anything to make my laptop work ;)
[12:26] <gnomefreak> Ubulette: https://code.launchpad.net/~gnomefreak/nspr/ubuntu-4.x https://code.launchpad.net/~gnomefreak/nss/ubuntu-3.x  fully updated and are both built in PPA
[12:28] <gnomefreak> finally finished with those :)
[12:37] <Ubulette> how do i tell cdbs to work in "mozilla" and not in "." ?
[12:37] <Ubulette> asac, gnomefreak ?
[12:37] <gnomefreak> Ubulette: those are the changes made that you wanted
[12:38] <Ubulette> gnomefreak, yes, but I'm wondering if we should integrate that for good or jsut keep it for ppa
[12:39] <gnomefreak> Ubulette: for now PPA not sure when asac wants to intergrate it to gutsy but the PPA is a mozilla team testing repo as mine was until domain issue
[12:41] <Ubulette> (my answer was DEB_SRCDIR)
[12:41] <Ubulette> gnomefreak, ok
[12:42] <gnomefreak> anyone happen to know how to strip DRM from a .wma
[12:43] <Ubulette> nope
[12:45] <Jazzva> asac: Returning the "getString" and "getFormattedString" to previous states (unapplying my changes) fixes the problem, but that way we're not able to call string from out properties file.
[12:45] <Jazzva> asac: As far as I can see, the problem might be somewhere in the test "if (!result)
[12:45] <Jazzva> "
[12:46] <Jazzva> anyone: Is it legitimate to test if string result is null using "if (!result)" in JS?
[12:47] <asac> yes i think so
[12:47] <Ubulette> checking for NSPR - version >= 4.0.0 (skipping)... yes
[12:47] <Ubulette> configure: error: system NSPR does not support PR_STATIC_ASSERT
[12:48] <Ubulette> for sure, xul trunk wants a fresher nspr :)
[12:48] <Jazzva> asac: Then I can't see the problem at the moment :/... I found a tutorial on MDC about .properties file and how to get strings from it... well, they're using the same we use...
[12:48] <asac> Jazzva: so you cannot find the pluginFinderWizard ?
[12:48] <Ubulette> checking for nspr-config... /usr/bin/nspr-config
[12:48] <Ubulette> checking for NSPR - version >= 4.0.0 (skipping)... yes
[12:48] <Ubulette> good
[12:48] <Jazzva> asac: But I think the problem comes in the "if" test
[12:48] <asac> Jazzva: try to look if you find the elemnt
[12:49] <asac> Jazzva: yes
[12:49] <Jazzva> asac: Since it fetches the string from our file, but it fails if it's not in our file...
[12:49] <asac> you should not just trust that the pluginFinderWizard element can be found
[12:49] <asac> if you cannot find it open an alert
[12:49] <asac> do the same for the first one
[12:49] <asac> its too dangerous to assume that all is fine
[12:51] <asac> Jazzva: try if you can open the resource the fallback refers to ... chrome://mozapps/locale/plugins/plugins.properties
[12:51] <asac> can you open that through location bar?
[12:51] <Jazzva> asac: but it fetches the string from pluginWizardString if I don't use the "if" test
[12:51] <Jazzva> I'll see
[12:51] <asac> Jazzva: the if is certainly not the problem
[12:51] <Jazzva> Yes, I can
[12:51] <asac> to be sure test result != null
[12:52] <asac> Jazzva: is the key we are looking for in that properties file?
[12:52] <asac> and if so ... is it a formatted string at all?
[12:52] <Jazzva> Nooo, it's nt.
[12:52] <Jazzva> *not
[12:52] <asac> you see
[12:52] <asac> thats the problem
[12:52] <Jazzva> But, how does it fetch it when I don't use the "if"?
[12:56] <Jazzva> Ok, I'll test with alert windows, to see if string is there
[12:58] <Jazzva> asac: Hmm, I don't know what I was thinking :/... I'm tired. I thought it was fetching strings without real looking at them... I thought it fetches them, since everything was fine...
[12:58] <Jazzva> asac: So, since they're no longer in chrome://mozapps/.../plugins.properties we need to provide them, right?
[01:08] <Jazzva> asac: Ok, I've placed few alert windows, just to check where it throws that exception. It throws it if the string is not found in the first file, that being "ubufoxPluginWizardString"...
[01:09] <Ubulette> asac, i'm done with the initial packaging of xulrunner (ie it compiles fine). remains to install the files from dist to the right place
[01:09] <Jazzva> It doesn't even get to "if (!result) doNext;"
[01:10] <Ubulette> it's with untouched sources (no patches). I wonder why mike has >70 patches