[01:23] strange.. [01:23] dist/bin/chrome/toolkit.jar contains content/global/bindings/findbar.xml [01:24] not global/content/bindings/findbar.xml [01:25] hmm, toolkit.manifest has: "content global jar:toolkit.jar!/content/global/ xpcnativewrappers=yes" [01:26] no idea what that means === Paddy_EIRE [n=patrick@89.240.243.205] has joined #ubuntu-mozillateam === hjmf_ [n=hjmf@7.Red-83-44-173.dynamicIP.rima-tde.net] has joined #ubuntu-mozillateam === Paddy_EIRE [n=patrick@89.240.243.205] has joined #ubuntu-mozillateam === cwong1 [i=chatzill@nat/intel/x-6f45754e31ceece9] has joined #ubuntu-mozillateam === Paddy_EIRE [n=patrick@89.240.243.205] has joined #ubuntu-mozillateam [09:20] Ubulette: that doesn't mean much [09:21] Ubulette: its confusing that the order or directories looks flipped but the manifest provides the real path info ... so its global + content + bindings + findbar.xml [09:35] i already thought that the resolvation strategy might get confused because there is a non-manifested toolkit.jar in dist/bin/chrome/ ... while the manifested one is in dist/bin/xulrunner/chrome/ [09:35] just removing the one in bin/chrome doesn't help though [09:59] lo [09:59] asac, did your flat install work ? [10:16] why would it [10:16] is just did it to better test it :) [10:16] as a side job i am currently reading code ... [10:17] i am unsure where the problem is, but it might be something with how or in what sequence things chrome is resolved [10:18] most important question: why the hell is browser.xml (i mean the content one not the skin one) not touched at all [10:18] is it due to some exception (like findbar) ... or isn't the css matched for the browser element ... or what [10:19] its the browser.xml in toolkit [10:19] that is not touched [10:19] :/ [10:19] but it has the definition of browser widget ... so [10:19] no idea :) [10:20] if a make install doesn't even work, i have serious doubts [10:20] well ... what i did is use the xulrunner dist/bin dir as --with-libxul-sdk= directory [10:20] which is probably what upstream does [10:20] they don't know about make install [10:20] so never try to verify with make install :) [10:20] anyway ... its the same [10:21] its definitly broken from what i see [10:21] i doubt that it works for them atm [10:22] but maybe its just something transitional/temporarily [10:22] anyway ... when we understand what is going on, we can fix it :) [10:22] ... as always :-D [10:24] well i think i should do a full debug xulrunner build as well === asac respinning ... and doing something else [10:26] Ubulette: can you find out why firefox still produces this almost empty toolkit.jar ? [10:26] (which doesn't even have a manifest for me) [10:32] today is editor update day ... emacs and vi received a security update :/ [10:33] yep, saw that yesterday [10:33] with tar too [10:34] Ubulette: you have a jar build? does ffox have a toolkit.jar with just dummyWindow.xul in it? [10:34] for you? [10:36] -rw-r--r-- 1 root root 1848474 2007-08-28 21:45 /usr/lib/xulrunner-1.9a8pre/chrome/toolkit.jar [10:36] -rw-r--r-- 1 root root 1852235 2007-08-28 20:40 /usr/share/firefox-trunk/chrome/toolkit.jar [10:36] -rw-r--r-- 1 root root 1966152 2007-08-18 22:25 /usr/share/firefox-granparadiso/chrome/toolkit.jar [10:36] almost the same size [10:37] btw, i have to go. i'll look into this later [10:37] see you [10:40] is trunk a xulrunner builder? [10:40] probably not [10:40] cu [01:07] PPA seems to still be dogfood [01:08] yeah [01:09] cwong1: there? who waas the hildon guy? [01:09] (nick) ? [01:12] why do i keep getting ilad failed to build iceape 1.1.4 but its in repo [01:17] oh lpia is an arch [01:18] yeah [01:18] gnomefreak: look in latest firefox branch commit i did [01:18] you need those as well [01:18] iceape fails to build on that [01:18] for lpia [01:18] yes all mozillas that are not fixed will fail [01:18] i fixed midbrowser + firefox for now [01:18] thunderbird sunbird will follow [01:19] what did you do to rules and control? [01:20] ok you changed build-deps [01:21] i dont even have gcc as a build dep [01:24] debian/rules, debian/control: use don't build lpia with gcc-4.1/g++-4.1 anymore, but [01:24] use gcc-4.2/g++-4.2 for all archs now. [01:25] grabbing source to see if i can figure out what you did [01:35] gnomefreak: loog at bzr log [01:35] shjould be clear which checkins you need [01:35] i pasted it above [01:35] no [01:36] look in past as well [01:36] there might be more you want [01:36] just redo same for iceape [01:36] starting at revo 85 [01:46] ok lunch === asac_ [n=asac@debian/developer/asac] has joined #ubuntu-mozillateam === hjmf_ [n=hjmf@182.Red-83-53-54.dynamicIP.rima-tde.net] has joined #ubuntu-mozillateam [02:33] asac: the orig.tar that you use with bzr is just the normal orig.tar that we make like with -trunk we use new-orig [02:34] depends [02:34] for stable firefox its the one in archive [02:34] otherwise probably yes [02:35] iceape is what im talking about that was first way to make one that came to mind [02:37] im gonna try with the orig.tar.gz that we uploaded to repos but use it with bzr [02:42] hopfully all patches apply === gnomefreak wishes this would hurry up and apply patches or fail to apply them [03:00] patch 99_configure-autoconf2-13-reconfigure fails [03:01] maybe iceape doesnt use autoconf [03:03] asac: does the configure-autoconf patch have to be used with force-no-pragma-visibility-for-gcc-4.2_4.3 [03:05] i dont see why this would fail other than iceape not using autoconf but i think it does for some reason [03:10] asac: ok not sure why its failing i dont see anything that tells me if iceape uses autoconf but im sure it does but patch fails to apply with a few like line 1 line 2 command not found errors and an unexpected token error [03:10] also line 3: ` 1 file changed, 835 insertions(+), 803 deletions(-)' failed. [03:11] --- [03:11] configure | 1638 +++++++++++++++++++++++++++++++------------------------------- [03:11] 1 file changed, 835 insertions(+), 803 deletions(-) [03:11] those are the 3 lines [03:12] should i drop that whole part and start with Index: mozilla/configure? [03:13] gnomefreak: configure you have to leave out [03:13] just apply the new configure.in patch [03:13] then run autoconf manually and update your iceape configure patch [03:13] (as usual) [03:17] you lost me [03:17] i have to leave out configure | 1638 [03:18] i havent had to run autoconf manully yet afair [03:20] asac: ok looking at the 99_configure.dpatch i had there from beginning patch starts with @DPATCH@ there is no mozilla/configure and all that other stuff. so should i drop all that crap in begining of patch start with @@ -55,16 +55,18 @@ and just add @dpatch@ to the start of it [03:21] hmmmmm [03:21] thats not right either [03:33] asac: well once i get this figured out ill push the patch after i correct it [03:36] gnomefreak: its always the same [03:37] you update the patch with results from a new autoconf2.13 rerun [03:37] gnomefreak: edit the patch [03:37] igore conflicts [03:37] rerun autoconf2.13 [03:37] exit dpatch edit shell [03:37] donw [03:37] done [03:39] what dir do i run autoconf1.13 in? [03:41] try to remember [03:41] you will find [03:42] you did that 4 times at least :) [03:42] in the same dir as configure.in is in [03:42] ok i ran it in /iceape/work/build-area/iceape-1.1.4 [03:42] i found it right after i asked [03:46] yeah [03:47] but you have to be in dpatch-edit-mode [03:47] now all is lost [03:47] and your configure is now borked [03:47] the idea was to update the patch [03:47] and not just the configure file [03:49] ok re grabbing the branch [03:49] cwong1: please ping me when there [03:50] i start build build will fail than i dpatch-edit to start with right? [03:52] ok so i open patch in dpatch-edit while its open i run autoconf2.13 in the dir [03:54] well ... if the new configure.in patch has been applied then yes [03:55] the only way to know that is to run autoconf2.13 first isnt it? [03:58] theres a step that im missing [03:58] i did as you said above 09:37 < asac > you update the patch with results from a new autoconf2.13 rerun [03:58] that was first instruction [03:58] so i ran autoconf and you said it was wrong [03:59] if that is right there is a step missing [04:01] gnomefreak: before autoconf is needed you need to modify configure.in [04:01] so be sure that you merged in my changes ... e.g. incl. the new patch [04:02] then if that is done [04:02] edit the configure configure patch [04:02] so manully apply the patch directly to configure.in? [04:02] by running autoconf2.13 [04:02] gnomefreak: no [04:02] integrate the patch in debian/patches/ [04:02] then just enter edit shell [04:02] its really simpl [04:03] add the NEW patch in 00list before the 99_configure one [04:03] new patch? [04:03] you said i had to modify configure.in [04:03] that would be new patch [04:04] without adding your changes to configure.in by hand how do i modify it [04:05] opening configure.in in dpatch edit shell will do nothing AFAIK i would have to edit it by hand to include the changes from the autoconfig patch [04:10] i already have a total of 2 configure patches one there from before an dthe new one that i took from ff [04:11] am i opening the first configure patch with dpatch or the file configure.in === ubotu [n=ubotu@ubuntu/bot/ubotu] has joined #ubuntu-mozillateam [04:21] there is something im not seeing in this [04:35] dpatch-edit-patch: * /home/gnomefreak/iceape/work/build-area/iceape-1.1.4/debian/patches/99_configure-autoconf2-13-reconfigure.dpatch does not exist, it will be created as a new dpatch. [04:35] dpatch-edit-patch: * Copying /home/gnomefreak/iceape/work/build-area/iceape-1.1.4 to reference directory. [04:41] it failed to open dpatch shell anyway [04:42] brb booting feisty to test something === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-mozillateam [04:49] bug 135572 [04:49] Launchpad bug 135572 in gedit "gedit crashes when pasting some code" [Medium,Incomplete] https://launchpad.net/bugs/135572 [04:53] gnomefreak: thats wrong [04:53] use the same name of the patch that is already there [04:53] gnomefreak: no ... there is a patch in firefox ... you need that as well [04:53] i took both firefo patches [04:53] try to read firefox bzr log carefully [04:54] both? [04:54] what both? [04:54] both [04:54] there is just one [04:54] the autoconfig and the force [04:54] the other is an update you have to redo [04:54] one [04:54] just take force ... autoconf you have to redo like above [04:54] just update the existing confiugre patch [04:54] in iceape [04:54] done [04:54] :) [04:55] i take a break now ... this mobile thing just kills me [04:55] maybe ill get to it tomorrow im not feeling well and this autocofig bs is getting to me [04:56] gnomefreak: do you understand what this is about? [04:56] gnomefreak: whenever you modify an existing confiugre.in patch or add a new patch for it [04:56] you have to update the configure patch [04:56] i got that [04:57] there is always one configure patch [04:57] not more [04:57] its always just take care that the new configure.in patch gets applied before the configure patch (which should be always last) [04:57] but problem is i cd into buildarea and run dpatch-edit-patch then edit (like in dpatch-edit) the configure patch [04:57] ignore any conflicts during application ... rerun autoconf2.13 [04:57] exit shel ... done [04:58] gnomefreak: there is a definite name of the patch [04:58] just look at the name in 00list [04:58] then it works [04:58] but ok dpatch-edit-patch [04:58] its not a "maybe name of patch" ... look in 00list ... be sure ... no problems [04:58] gnomefreak: so you still haven't integrated my patch? [04:58] or do i use exsiting configure patch [04:58] gnomefreak: i thought you are stuck at confiugre patch [04:59] asac: i cant open dpatch shell [04:59] gnomefreak: you have to add my new patch to the dpatch system as a distinct patch [04:59] if that is done (e.g. its named in 00list) [04:59] then you edit the *one* and *only* configure patch by dpatch-edit-patch ... autoconf2.13 [04:59] but if i dont add your patch to iceape it wont be in 00list [04:59] exit [04:59] done [04:59] gnomefreak: you have to add it ... why wouldn't you? [05:00] because you just said dont add your patch i have to make my own [05:00] well .. you have to make a dpatch file out of it [05:00] (not a plain patch) [05:00] its basically .. copy over [05:00] rename (so it has .dpatch) extension [05:00] add the dpatch header into file (like all the other dpatch files) [05:01] add the name (what comes before .dpatch) to 00list [05:01] done [05:01] there are hundreds of ways ... but I was sure that you know how to add a dpatch :) [05:02] ok so if ther eis only 1 confiure patch no more than what do i do with the one iceape already has [05:02] only requirement is that it needs to be in 00list before the 00_configure patch ... thats all [05:02] gnomefreak: you never take the configure patch [05:02] gnomefreak: only take the configure.in patch (the force one) [05:02] the configure patch that iceape has you have to update afterwards [05:03] on like describes a few times above :) [05:04] ok so i open the configure patch i have now in iceape in dpatch and just add your changes to it? === gnomefreak will see what i can do later this afternoon i cant work on it right now it pisses me off too much [05:05] brb === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-mozillateam === hjmf_ [n=hjmf@7.Red-83-44-173.dynamicIP.rima-tde.net] has joined #ubuntu-mozillateam [05:42] asac: I will get you the hildon contact at nokia as soon as bob comes in. I forgot all about it. Sorry. [05:49] asac: the person you want to talk to is Tommi and he signed in #ubuntu-mobile as tko [05:54] cwong1: tko? [05:54] asac: that is he's login id [05:56] asac: I met him at google and he knows libhildon pretty well. [05:59] cwong1: ok cool [05:59] me fighting to get a real development :) [06:00] cwong1: do i really need a target? [06:00] k [06:00] (in image-creator) [06:00] you will need hildon to test your stuff, so yes [06:00] cwong1: what shall i select? [06:00] maccaslin [06:00] as functional block [06:00] samsung-full-stack [06:01] ok ... i had menlow first ...there was only gnome-mobile which was broken [06:03] hopefully this works [06:03] should work ... then just follow the instruction in moblin.org to test the target [06:08] cwong1: you mean http://www.moblin.org/howto_app-dev.html ? [06:08] under "Target Environment" [06:08] ? [06:08] its under http://www.moblin.org/howto_create-image.html [06:09] Step 5 [06:09] ok [06:09] its the same from what i see [06:09] could be [06:10] yes its the same [06:10] cwong1: i assume there is a full hildonized app preinstalled? [06:10] yes [06:10] so i can check that it actually works? (e.g. window events) [06:10] the calculator === Ubulette_ [n=Ubulette@APuteaux-153-1-56-105.w82-124.abo.wanadoo.fr] has joined #ubuntu-mozillateam === Ubulette_ is now known as Ubulette [08:19] lo [10:16] asac, part of the nsinstall patch has been accepted === Jazzva [n=sasa@cable-89-216-130-161.dynamic.sbb.co.yu] has joined #ubuntu-mozillateam [10:42] Evening... [10:43] hi [10:43] Hello, Ubulette... [10:43] it's quiet today [10:43] Really? [10:44] Oh.. [10:45] I weren't here for two days.. Got the new HDD, copied all the data from the old one to the new one and installed Ubuntu on a friend's computer today :D.. === Jazzva : "Come to the dar... ahem, Ubuntu side, Luke" :) === cwong1 [i=chatzill@nat/intel/x-20c39ff6bd0b9514] has joined #ubuntu-mozillateam [10:53] Jazzva, lol [11:21] asac: ping [11:42] cwong1: pong [11:43] asac: Can we make another release with the new toolbar on the bottom? [11:45] well ... we could also have a semi-hildonized menu if you want :) [11:45] it finally works ;) [11:45] asac: Is that working? [11:45] yeah ... well for now its just that the menu bar hides/shows when you click the panel button [11:45] great [11:45] but making a popup out of it is now something left for the readers ;) [11:46] i cleaned stuff up a bit ... and will commit this [11:46] cwong1: have you tried to open a new window? [11:46] cwong1: for me the statusbar and the bookmars reappear in the second window [11:46] cwong1: can you fix that for real? e.g. strip it from midbrowser.xul instead of localstore.rdf or whatever you did? [11:47] asac: I will look into it. [11:47] if you can fix that tilll tomorrow, i will merge down the clean parts from working to release branch tomorrow [11:47] or till today end of your workday of course :) [11:48] asac: do I need your new code to reproduce the problem? [11:48] oh ... what happens if you open "file -> new window" ? [11:49] it probably still opens for you the old, standard browser, right? [11:49] asac: one thing we will want to do is to disabllow more than 1 browser widow [11:49] why? ... works pretty well here :) [11:49] it should definitly be fixed ... even though we don't allow it [11:49] asac: thats what Bob said to do [11:50] yeah ... thats ok [11:50] I will go ahead and fix that anyway [11:50] but the window strip down should be done proper in .xul anyway [11:50] yeah [11:50] backout the rdf patch [11:50] and do it directly in midbrowser.xul [11:51] ok, will do [11:51] cwong1: you have any idea how toolbar is ment to work= [11:51] from what i see its not really implemented in hildon lib [11:51] no it is not [11:51] rg/projects/bonecho? [11:51] for now we could hide and show it like the popup ... [11:51] he? [11:51] probably an accident ;) [11:52] yes it was [11:52] I was going to ask u a different question [11:52] ok [11:52] go ahead [11:52] can we change the default link to point to a file instead of www.mozilla.org/projects/bonecho? [11:52] what is the default link for you? [11:52] the homepage is already fixed, right? [11:53] you mean the throbber? [11:53] I meant when it first come up it should point to a file like /var/www/..../index.html [11:54] like the firefox from ubuntu points to /usr/share/../somefile [11:54] currently we open moblin.org, right? [11:54] just to not talking about different things here [11:55] yes but we want to point to a file instead becuase if you run it from a firewall, it sits there for a long time until it times out [11:55] yeah ... you can do it in the same way as you changed to use moblin.org [11:56] does that index.html already exist? [11:56] Yes, in the old package that I did before. [11:57] I can change the link in the code and have our home flash plugin install the page [11:57] cwong1: why not include it in the chrome midbrowser.jar ? that would allow you to change the page in midbrowser language packs as well [11:57] asac: how do add the html page to the jar? [11:58] add it to jar.mn [11:58] use the same pattern you see for midbrowser.xul there [11:58] then try to reference it with [11:58] chrome://midbrowser/content/midbrowser-startpage.html [11:58] ok. sounds good [11:58] in location bar ... if that works try to flip homepage setting to that page [11:59] will do [11:59] later that page should only contain layout ... content should go to a .dtd file so it becomes translatable [11:59] what about the upgrade check that is in WORKNG branch, can you not include that in the release? [12:00] which commit? [12:00] have a link go git web? [12:00] s/go/to/ [12:01] With latest checkout it takes a while for the browser to come up and last I chat with you, you said it is because of the upgrade check [12:01] huh? [12:01] no ... its a one time thing ... if the application is upgraded the next restart takes some time ... but not the ones afterwards [12:02] can we not do that one time thing? [12:02] no [12:02] i somehow have the feeling we are talking about different things [12:03] its not an upgrade check that i refer to ... but its an *upgrade* that firefox has to do with your profile directory ... e.g. reregistering xpcom components al [12:03] but it hardly takes longer than 2-3 seconds [12:03] on a fresh build, it starts up slow right becuase of the one time check, right? [12:03] and is just the first time you start it [12:03] its not a check [12:03] if you are behind a firewall [12:04] and proxy is not set, it takes more that 3 seconds [12:04] oh.. so during the upgrade, it doesn't go out to the web and search for components? [12:04] cwong1: about:config [12:05] search for update [12:05] set to false [12:05] app.update.auto [12:05] app.update.enabled [12:05] extensions.update.enabled [12:05] see if your issues go away [12:05] ok [12:05] thanks [12:06] anyway ... there are more pressing issues than that [12:06] really [12:06] agree [12:06] those things should go to the todo list that bob and i started once [12:07] no idea where that ended up ... but i think in wiki? [12:07] We are going to setup a wiki in moblin.org soon [12:07] yeah ... but we had worked out 10 points or something ... he wanted to post them [12:07] somewhere ;) [12:08] I will get the list form him [12:08] :0 [12:09] So are the hildon code check-in? [12:16] well ... takes a bit ... want to have clean checkin [12:16] but already finished locally [12:18] asac, i fixed ff3+xul [12:20] cwong1: ok let me push [12:20] cwong1: hold still for a few :) [12:20] ok [12:20] Ubulette: really? [12:20] yes [12:20] Ubulette: you rock ;) [12:20] Ubulette: what was the culprit? [12:20] asac: I am anxious to see how that look like [12:21] asac, mostly a mismatch of 3 days between xul and ff3 with some changes in browser.jar [12:22] which means we'd better package both at the same time [12:25] cwong1: http://www.moblin.org/repos/?p=projects/mobile-browser.git;a=shortlog;h=WORKING [12:25] cwong1: read the long logs of the checkins to get an overview [12:25] asac: k will pull and build and red the logs [12:25] s/red/read/ [12:26] cwong1: damn thing git web doesn't break lines ;) [12:26] next time i will to id here in commit log directly [12:26] maybe i will retype when merging down to release branch [12:26] :) [12:26] sounds ok [12:26] cwong1: i didn't test your checkin [12:27] cwong1: so if its break it was you :) [12:27] that was just a minor change [12:27] let me rebuild [12:27] yeah minor changes can have deep impacts :) [12:27] Ubulette: yeah ... thats good ... you see the checkin in bonsai that fixed it? [12:27] Ubulette: would just be curious [12:28] cwong1: i will implement F4 trigger as well ... as i saw that hildon does it as well (e.g. open menu when pressing F4) [12:29] asac: k [12:29] cwong1: for toolbar ... whenever we know what they do, we can probably do it as well [12:29] cwong1: i didn't really find the piece of code in libhildon that does that [12:30] asac: are you referring to the toolbar at the top? [12:30] no ... to the toolbar at the button :) [12:30] i only talk about application things ;) [12:31] Ubulette: that said ... maybe we should always checkout origs with tag ... e.g. trunk is always date tag of today 00:00 [12:33] we should also find a way to co something smaller now instead of 'browser' [12:33] Ubulette: right [12:34] Ubulette: maybe directly from hg even :) [12:34] Ubulette: i think you need files of top-level directory + browser + extensions + build + config [12:35] yep, something like that, i made a diff already [12:36] i need to commit a few things 1st [12:36] i drop firefox-trunk-dev [12:36] why? [12:36] empty [12:36] firefox probably still has headers [12:36] hmm [12:36] there should be some [12:36] or isn't there any idl file in browser/ hierachy anymore? [12:37] cwong1: you can enable logging of the hildon event service component by export NSPR_LOG_MODULES=hildon:5 [12:37] oh, you're right, i've kept a few things in, but so are gone [12:37] cwong1: before starting it [12:37] cool [12:42] cwong1: i saw that your image-creator still creates i386 chroots ... not lpia [12:42] will you switch? [12:42] asac, no more dev files in debian/tmp, but some .idl/.h in moz/dist :P [12:42] (soon is the question) [12:42] Ubulette: wow ... so make install still broken? [12:43] probably [12:43] i'll look at it once i've committed the rest [12:43] hmm ... maybe the packager.mk now doesn't think that firefox has a -devel part? because its with-libxul-sdk? [12:44] possible [12:56] cwong1: still building ;) ? [12:57] asac: for lpia, you need to ask rusty [12:57] asac: build is don and I am going to give it a try here [12:59] asac, trunk pushed [01:00] cwong1: cross-fingers ;) [01:00] asac, xul too [01:00] asac: I screw up. It was building from the Master not Working.. :( [01:00] pushing my tarballs.. [01:00] cwong1: oh dear ;) [01:00] cwong1: i think you don't need a full rebuild [01:00] cwong1: just a make [01:00] y [01:01] cwong1: the important part is that you rebuild the gtk/ tree so there is no hildon window anymore [01:01] and the you build the midbrowser tree [01:01] k [01:02] but if it fails ... maybe consider to rebuild :) [01:02] but then i will be in bed :/ [01:02] Ubulette: cool ... thats really good news [01:02] Ubulette: i will try it tomorrow i guess [01:03] Ubulette: are you running full install? [01:03] or in dist/ ? [01:03] the debs [01:03] ok ... the firefox deb doesn't contain the xulrunner that was copied to it, right? [01:03] right [01:04] i removed that [01:04] if you change the name of the gre.d config entry (in brackets) ... to a9 or something [01:04] does it still find the right xul? [01:04] oops, forgot to Build-Depends xul-dev [01:04] np :) [01:04] Ubulette: actually is in applications.ini a maxVersion? [01:05] fta@ix:~ $ xulrunner --find-gre 1.9a8pre [01:05] /usr/lib/xulrunner-1.9a8pre/libxpcom.so [01:05] fta@ix:~ $ xulrunner --find-gre 1.9a9 [01:05] fta@ix:~ $ xulrunner --find-gre 1.9a8 [01:05] fta@ix:~ $ [01:05] doesn't smell good [01:06] Ubulette: well ... please try what i asked [01:06] i think that seneraio better projects what is actually needed [01:06] drop maxVersion from application.ini [01:06] if there is any [01:06] [Gecko] [01:06] MinVersion=1.9a8pre [01:06] MaxVersion=1.9a8pre [01:07] yeah drop that Max thing [01:07] just remove the line [01:07] then bump the name in gre.d ...conf [01:07] and see whats coming ;) [01:09] root@ix:/etc/gre.d # cat 1.9a8.system.conf [01:09] [1.9a8] [01:09] GRE_PATH=/usr/lib/xulrunner-1.9a8pre [01:09] xulrunner=true [01:09] no that is maybe lower [01:09] it runs without complaining [01:09] cool [01:09] even without maxVersion? [01:09] aeh with [01:09] yep [01:09] no [01:10] without [01:10] ok thats fine [01:10] then we know how to make the stub probe for compatibility [01:10] well lets hope that components will complain on load [01:10] # cat 1.9.0.system.conf [01:10] [1.9.0] [01:10] GRE_PATH=/usr/lib/xulrunner-1.9a8pre [01:10] xulrunner=true [01:10] still ok [01:10] and that firefox components don't depend on internal things :/ [01:10] yeah [01:11] Ubulette: another try would be to forcefully bump real version of xulrunner [01:11] to 1.9.1 [01:11] or something [01:11] in xulrunner/config/... [01:11] and config/*version* [01:11] something like that [01:11] forgot the right names just now [01:12] put Milestone=1.9a7pre in /usr/lib/xulrunner-1.9a8pre/platform.ini [01:12] fta@ix:~ $ firefox-trunk [01:12] Error: Platform version '1.9a7pre' is not compatible with [01:12] minVersion >= 1.9a8pre [01:12] maxVersion <= 1.* [01:12] fta@ix:~ $ [01:12] and in milestone*.txt [01:12] its in config/ as far as i know [01:12] maybe they eliminated it by now though