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