[06:14] asac, do you of any way to force a crash for oopp testing? [06:17] LLStarks: find the oopp PID and kill it :) [08:40] m0rning [10:07] fta: code.google.com/p/chromium/issues/detail?id=41145 [10:07] I'll have a field day, today on ch [10:07] 3 more bugs to repoprt [10:09] fta: http://code.google.com/p/chromium/issues/detail?id=41146 [10:13] LLStarks: right. kill -SEGFAULT or something to the process [10:34] asac - should i branch firefox for lucid now? micahg has started updating to 3.6.4 in .head, but i wouldn't mind fixing this NSS issue in 3.6.3 before final freeze [10:41] chrisccoulson: yeah. lets do a .lucid branch now [10:41] remember to set it to mature ;) [10:41] ok, i'll do that now then [10:41] cool [10:42] what is the status of html5 client side database (sqlite) in firefox? any idea? [10:42] chrisccoulson: remember to also cherry pick the patches we talked about [10:42] fta2: not in 3.6.x ;) [10:42] sorry coulnt stop [10:42] fta2: do we need another chromium update round? [10:42] or is all set for release? [10:43] i need to send the last beta update (a few days old, already in the ppa) [10:43] plus a patch for chrisccoulson [10:44] fta2: homepage? [10:44] err search ;O) [10:44] fta2: yeah. can you do those two updates today? [10:44] would be cool have that bake asap [10:44] fta2: one thing [10:45] fta2: the licenscheck generator ... any idea how to make that properly sorted? [10:45] e.g. so we can update and get a reasonable diff? [10:45] i wanted to push all this to debian so we can send stuff to debian unstable for lucid+1 [10:45] ... but guess i need one more licensing update round [10:45] (i'm busy with work atm) [10:46] kk [10:57] asac - are we keeping the version numbers in the bzr branches? (using firefox-3.6.lucid rather than firefox.lucid) [11:01] chrisccoulson: yeah. usually we do [11:01] e.g. just s/head/lucid/ [11:01] thats not true for thunderbird [11:01] because we never had two versions at the same time [11:02] at some point we might wanna go back to firefox, but not before all releases with two versions are flushed ;) [11:02] asac - ok, thanks. i'll stick with firefox-3.6.lucid for the lucid branch then [11:03] kk [11:03] chrisccoulson: lets branch all the rest too [11:03] e.g. xul [11:03] etc. [11:03] tbird [11:03] yeah, no problem [11:03] well, if we know we are doing another round before luci [11:03] d [11:03] we can stick to .head [11:03] until that [11:05] bdrung: did the md sync happen? [11:05] bdrung: btw, i feel relucant to do the pref transition in lucid still. i will merge your changes to .head though so it gets up right when m opens [11:05] i think its ok. and i owe you a beer [11:13] ccheney: hey [11:13] ccheney: did you fall off the face of earth ;)? [11:37] asac: notify-osd is in BOTH top corners of my screen. how can I run it in debug mode? [11:39] asac: m-d is not yet synced [11:40] bdrung: did you overload it with .22? [11:41] asac: overload? [11:41] didnt you upload .22 now? [11:41] e.g. is .21 still avail for synching? [11:42] whats the change for .22? [11:43] i can upload .21~0ubuntu1 [11:44] asac: i uploaded .22 - syncing this version is save. [11:44] https://bugs.launchpad.net/ubuntu/+source/mozilla-devscripts/+bug/557081 [11:44] Launchpad bug 557081 in mozilla-devscripts "Sync mozilla-devscripts 0.22 (main) from Debian sid (main)" [Wishlist,Confirmed] [11:44] well. i didnt review it [11:44] only two changes [11:44] yes, but adding another new feature etc. [11:45] what is the buildsystem for? [11:45] asac: you can use the dh 7 oneliner: dh --with xul-ext --buildsystem=xul_ext $@ [11:46] and what does that do? [11:46] what is the xul_ext build system? [11:47] ok using pack/unpack [11:47] on build it run "xpi-pack . package.xpi", on install "install-xpi package.xpi" and "rm -f package.xpi" on clean [11:48] yes [11:48] so run a full rebuild of all extensions ;) [11:48] install-xpi changed [11:48] again [11:48] i can just upload .21 as its now [11:51] k, will do a full rebuild test. [11:51] problem is that i had enough issues during freeze to fix in my past.... its really annoying [11:51] thanks [11:54] ok commented that on bug [12:04] chrisccoulson: did you have a fedora VM? [12:05] we need to verify that mozilla bug 541319 is an issue everywhere [12:05] Mozilla bug 541319 in Graphics "firefox does not honour gtk/gnome settings in FF3.6 on Ubuntu/lucid since using --disable-system-cairo" [Normal,Reopened] http://bugzilla.mozilla.org/show_bug.cgi?id=541319 [12:05] e.g. gtk settings don get applied with in-source cairo [12:07] asac - i've not got a fedora VM, but i can try out a live CD in a bit [12:13] chrisccoulson: please check ;) [12:13] e.g. with upstream builds: a) does changing the hinting/lcd settings in fonts dialog change how firefox looks like [12:13] e.g. do they have the same bug [12:14] chrisccoulson: whats your bmo address? [12:14] asac - chrisccoulson@ubuntu.com [12:14] ok simple enough. will remember that ;) [12:21] asac: moving the config file would close bug #493805 [12:21] Launchpad bug 493805 in ubufox "ubufox 0.8 leaves FF 3.0 folder in /etc" [Low,In progress] https://launchpad.net/bugs/493805 [12:34] asac: is it ok to rename ubufox? [12:37] i will merge that to the .ubuntu branch [12:37] but not for lucid [12:37] i just dont have the time to deal with any eventual regressions [12:38] asac: deferring the rename to m too? [12:38] is it really worth making a more minimal packaging change? [12:38] e.g. without config file transition etc. [12:38] i dont think so [12:39] asac: if you do not move the config file, we disable m-d new feature and leaving the config file where it is. [12:39] yes, still i have to go and hunt stuff through NEW, get seed changed etc. [12:39] i dont really care. i just dont want to drive all this ;) [12:40] its a ubuntu-core-dev branch, so you are definitly entitled to get this done ;) [12:41] asac: i would like to merge everything into ubuntu-core-dev branch. i think these changes are safe. i have tested the config file movement and the procedure is well tested ( taken from http://wiki.debian.org/DpkgConffileHandling ). [12:42] bdrung: right... just take the lead and the responsibility ;) and get FFe for things that need one etc. [12:42] having the config file *firefox-3.0* is incorrect ;) [12:42] i just dont like the idea to get an update through freeze and then having to answer why we pushed such a change without any clear direct benefit for the lucid cycle [12:43] yes, thats right. its wrong there. [12:43] but is it a release blocking bug? [12:43] asac: when moving, then to the correct place [12:43] sure [12:44] thats why i would prefer to do the full thing [12:44] just feel uncomfortable to do that for lucid ... [12:45] i know, that it's not the best time for this change [12:46] so we should get a) a package up for testing the upgrade path somewhere ;) [12:46] asac: k, will upload it to my PPA [12:46] and then verify the butt out of us and then pushing this through dropping a few feature changes [12:46] if its a feature at all [12:46] for me a package reorg is > feature ... but some might disagree [12:50] it will bring more consistency [13:03] asac, do i need to ask for a FFe each time i need to update chromium??? [13:06] asac: bug #557081 [13:06] Launchpad bug 557081 in mozilla-devscripts "Sync mozilla-devscripts 0.22 (main) from Debian sid (main)" [Wishlist,Fix released] https://launchpad.net/bugs/557081 [13:07] col [13:07] fta2: did they fix any security stuff etc.? [13:07] i would say no ... but thgen i am too used to ffox stuff [13:08] in the end same logic should apply there [13:08] at least when we get a stable channel build at some point ;) [13:08] asac, well, channels are sort of continous upgrades [13:09] even the future stable channel will jump from time to time [13:10] sure [13:10] though stable channels supposely get decent QA upstrema [13:10] which is why we can do this for mozilla [13:10] anyway, in practice you have to get FFe for every update [13:10] we should ask Technical Board for a standing FFe [13:10] so maybe do it this time and then lets remember to get this sorted by TB [13:12] asac, http://paste.ubuntu.com/413085/ [13:14] yeah. but stable channel doesnt get that bad bumps ;) [13:14] we need to find a way to identify whether a beta release is good enough [13:15] one thing is to wait and see if they bump again within a week i guess [14:33] good ... seems we have a kernel regression ;) [14:33] sont reboot on thinkpads into -20 ;) [14:54] asac: ubufox is now in my ppa [14:55] Chrisccoulson hi [14:55] hi rickspencer3 [14:55] ;) [14:55] hi asac [14:55] hi rickspencer3 [14:55] chrisccoulson so, I haven't been tracking this too well ... [14:55] so as a any good pointy haired manager, I shall interupt you and ask instead of investigating myself ... [14:56] bdrung: ok isnt published yet [14:56] have the default search provider changes rolled out to the distro? [14:56] rickspencer3, yeah, they were rolled out last week for konqueror and firefox [14:56] coolio [14:56] chromium is being worked on, and i'm going to look at epiphany too [14:56] k [14:59] asac - did you see bug 561124? it seems the in-source NSS causes some issues [14:59] Launchpad bug 561124 in openjdk-6 "firefox sets LD_LIBRARY_PATH which breaks the icedtea6-plugin" [High,In progress] https://launchpad.net/bugs/561124 [15:02] chrisccoulson: isnt that the lack of .chk files that causes this? [15:04] asac - i'm not too sure actually [15:07] chrisccoulson: nss in firefox should be compatible [15:07] so its hopefully .chk [15:11] asac: ubufox is now published [15:30] asac: no, just been really busy with OOo patching/bugfixing [15:43] kk [16:32] weird. bug 555512 [16:32] Launchpad bug 555512 in chromium-browser "Flash completely fails to execute from Google Chrome 5.0.342.7 beta version." [Undecided,Incomplete] https://launchpad.net/bugs/555512 [16:32] could someone confirm?? [16:44] asac: does tbird 3.0 share the xul192 codebase? what about seamonkey? [16:45] jdstrand: no, tb3 is 1.9.1, seamonkey 2 is also 1.9.1 [16:45] micahg: ok thanks [16:45] asac: can you check my symlink fix for bug 558620: http://pastebin.com/T0LJCkUj [16:45] Launchpad bug 558620 in thunderbird "Thunderbird moves profile folder to .thunderbird.upstream" [Low,Triaged] https://launchpad.net/bugs/558620 [16:48] chrisccoulson: there's no reason for thunderbird-gnome-support to provide gnome-web-browser, right? [16:49] micahg - i don't think so [16:49] chrisccoulson: k, do you want to check my symlink fix above? [17:28] does ubuntu's firefox use the system's cairo package? [17:28] I'm looking at the unpacked apt-get source folder, and seeing cairo [17:28] if I patch that, do I actually change anything? [17:29] micahg - ok, i will have a look at that shortly [17:29] cwillu_at_work, it uses in-source cairo. why are you trying to patch that anyway? [17:30] chrisccoulson, testing a handful of patches re: rendering/scrolling performance on arm [17:31] chrisccoulson, but the system's libpixman is used? [17:35] fta: flash is working in trunk daily [17:35] 32 wraper [17:36] cwillu_at_work, yeah, that's right [17:36] chrisccoulson, and this is widely consider somewhat insane, right? :p [17:36] or did I miss a readme that says which source trees are just there for reference? [17:37] cwillu_at_work, i'm not sure what you mean [17:38] chrisccoulson, I see /build-tree/mozilla/gfx/cairo/{cairo,libpixman} [17:38] yeah, i just noticed that too [17:38] * cwillu_at_work starts to cry [17:39] cwillu_at_work, hang on, i might be getting confused here [17:39] chrisccoulson, I'm hoping so :D [17:39] firefox-3.5 depends on libcairo2 [17:48] cwillu, hint: DEB_MIN_SYSDEPS in debian/rules [17:48] cwillu_at_work, ^^ [17:49] thanks [17:51] cwillu_at_work, so, in source pixman too. i'm getting confused because i see it loading cairo and pixman from /usr/lib, but that's a consequence of using gtk [17:52] chrisccoulson, I know for a fact it uses the system's libpixman, because I patched it with some buggy neon blitters which caused rendering corruption in firefox [17:53] * cwillu_at_work still needs to look at debian/rul;es [17:58] fta, that's new in 3.6? [18:32] [reed]: there were issues with our bugzilla plugin, right? [18:32] whats the status on that? any idea? [18:34] <[reed]> asac: it's not needed now, no? [18:36] <[reed]> asac: Bugzilla 3.4 supports it already ... [18:54] [reed]: afaik we already pair with bugzilla [18:54] but i remember that you disabled someting etc. [18:55] <[reed]> yes, because launchpad was doing stupid things [18:55] <[reed]> I think that's fixed now [18:55] <[reed]> I guess I could re-enable launchpad's account [18:55] [reed]: right. what were those issues? [18:55] do they need to be fixed/escalated? [18:55] <[reed]> I think they are fixed now [18:55] ok cool. that was about multiple tasks? [18:56] <[reed]> or something [18:56] <[reed]> bug tracking / watching [18:56] <[reed]> see also [18:56] <[reed]> micah knows all the details [18:56] ok good [18:57] will check with him [18:57] please reenable ;) [18:57] somehow some bugs were linked, but not all [18:57] so thats the reason :) [19:22] [reed]: I thought the LP account was reenabled already. [19:22] chrisccoulson: did you have a chance to look at my symlink fix [19:23] micahg - sorry, just looking at it now [19:23] chrisccoulson: np [19:29] chrisccoulson: do you have time to push a conkeror fix today? [19:29] micahg - yeah, can do [19:29] chrisccoulson: k, then I'll file the bug for it [19:30] micahg - what other outstanding items do you have for feature freeze? [19:30] chrisccoulson: nothing that's filed AFAIK [19:30] vlc, I need to test, but I'll do that tonight [19:31] micahg - we still need to decide on what to do about sugar / pyxpcom [19:32] micahg: what's with vlc? [19:32] bdrung: fix for xul192 [19:32] FTBFS [19:32] k [19:33] bdrung: I've backported most of the fixes from upstream git [19:35] micahg - were you working on firegpg? [19:35] err [19:35] sorry, firebug [19:35] * chrisccoulson gets confused [19:35] chrisccoulson: no, I was working on firegpg, AFAIK, firebug has no arch specific components [19:36] micahg - oh, ok. firebug has a recommends on xulrunner-1.9.1 [19:36] i'm just wondering if it's worth an upload just to drop that [19:37] chrisccoulson: idk, bdrung jsut did a round of uploads for extensions [19:38] i did that, because m-d supports config files and installs the extension in another directory [19:43] asac - did you say you were ok with dropping seamonkey? [19:43] chrisccoulson: I thought we were updating it... [19:44] micahg - is anybody working on that though? [19:44] chrisccoulson: well, someone did work on the patches, but it's only partial because he altered how the package worked [19:45] chrisccoulson: I was going to do it, but it was suggested that someone else do it as I"m supposed to be porting [20:06] micahg - so, is it thunderbird which is creating ~/.mozilla-thunderbird/profile.folder/Mail/smart mailboxes-1/ ? [20:07] chrisccoulson: it's most likely an extension with a hard coded path IMHO [20:07] micahg - ok. the patch looks sensible then [20:07] chrisccoulson: why did you drop mozilla-noscript? [20:08] (i need to actually test it too, but if some extensions are hard-coding paths, then the patch makes sense [20:08] bdrung - see conversation yesterday [20:08] bdrung: it releases too frequently to keep properly up to date in archive [20:08] k [20:08] basically, they release pretty much weekly with new security fixes, and asac and micahg agreed it is too much of a moving target [20:09] yeah, what micahg said ;) [20:12] chrisccoulson: k, I just pushed 2 thunderbird fixes, do you think it should be pushed now or at the end of the week? [20:13] chrisccoulson: oops, I should fix the wording on there [20:13] micahg - we should probably aim for wednesday afternoon. that's one day before final freeze and still gives us a chance to put any other fixes in without doing too many builds [20:14] chrisccoulson: ok [20:15] bdrung - did you have any response about the license for stumbleupon? [20:15] chrisccoulson: no [20:15] bdrung - ok, thanks. [20:23] chrisccoulson: what about bug 561216 [20:23] Launchpad bug 561216 in firefox "Firefox is not building against system NSS and system NSPR" [High,Triaged] https://launchpad.net/bugs/561216 [20:38] micahg - that shouldn't be a problem really. the icedtea plugin issue is strange, as the in-source and system nss versions are currently the same [20:39] chrisccoulson: indeed, but I thought we went through all that work not to use the in source versions [20:40] including what I did with the PPAs [21:04] jdstrand: since there's a USN for NSS, are hardy -> jaunty going to get updates as well? [21:04] chrisccoulson ^^ [21:08] micahg - the changes in NSS also seems to require quite a large xulrunner change, which hasn't been done upstream for 1.9 [21:09] chrisccoulson: ah, so we have to wait till we push 3.6.x?\ [21:09] micahg - most likely. [21:11] micahg - did you do any work for porting miro? [21:11] chrisccoulson: so back to the in source issue...it also affects the dailies (which are on hold for the moment) and the firefox-stable PPA [21:11] chrisccoulson: yes [21:12] micahg - the firefox-stable PPA is shipping updated system nss versions at the moment isn't it? [21:13] is miro ready btw? i can do some sponsoring if you like [21:14] chrisccoulson: yes, but the build is ignoring the system NSS versions due to DEB_MIN_SYSDEPS being set [21:14] chrisccoulson: I was doing some testing and there seem to be some issues still [21:14] ah, yes [21:14] what sort of issues are you seeing? [21:15] chrisccoulson: I get a python crash on my system for Miro, but a new Lucid live CD didn't have the issue with the version in archive [21:15] I didn't get a chance to check the version from the PPA in the live env [21:16] oh, i thought you meant you were seeing issues with in-source NSS ;) [21:16] heh [21:17] chrisccoulson: I'll attach the debdiff and build log for my conkeror update which is ready though [21:18] thanks [21:18] how did you recreate the miro crash? [21:19] chrisccoulson: just clicking on something in the window does it for me with the versionf rom th ePPA [21:21] hmmm, it's not crashing here (i just did a build with 192) [21:22] chrisccoulson: no python crash?> [21:22] app doesn't crash, just a python crash [21:22] ah [21:22] chrisccoulson: bug 561708 [21:22] Launchpad bug 561708 in conkeror "Backport fixes from upstream git related to xulrunner-1.9.2" [Medium,Confirmed] https://launchpad.net/bugs/561708 [21:27] micahg - i don't get any issues here. but, if you're seeing an unhandled exception rather than a crash, then we probably shouldn't block uploading for that (we can fix that, and remember that apport gets disabled this week too) [21:28] anyway, dinner time. bbiab [22:20] Anyone avail? [22:20] Noticed some failed builds in the PPA... my browser keeps crashing [22:20] these things related? [22:21] storrgie: probably not, which PPA? [22:22] https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa [22:23] http://pastebin.com/ZnytGg6w [22:23] thats all I have [22:24] storrgie: bug 513887 [22:24] Launchpad bug 513887 in firefox "Flash, Java, etc. does not work with out of process plugins and causes Firefox to become unresponsive" [High,Triaged] https://launchpad.net/bugs/513887 [22:24] dom.ipc.plugins.enabled.libflashplayer.so to false is a workaround [22:30] micahg - ok, conkeror uploaded [22:30] chrisccoulson: thanks [22:33] chrisccoulson: classpath is still up for grabs if you're looking for something to port :) [22:36] chrisccoulson: I'm also assuming the way I made the patches for conkeror was ok, right? [22:37] micahg - yeah, those were fine thanks [22:37] chrisccoulson: yeah, that and what I'm doing with vlc were my first experiences with git format-patch [23:24] micahg - redhat just disabled the gcjwebplugin in classpath for xul192 [23:24] s/redhat/fedora [23:24] https://bugzilla.redhat.com/show_bug.cgi?id=548783 [23:24] bugzilla.redhat.com bug 548783 in gcc "gcc doesn't build against xulrunner-devel-1.9.2" [Medium,New] [23:24] * micahg needs to learn to check if someone else did the work already :-/ [23:26] chrisccoulson: sounds good, do you want to take care of it? [23:26] micahg - yeah, will do that now [23:26] chrisccoulson: thanks [23:27] chrisccoulson: can you file a bug and link the fedora bug as well so we have a record? [23:27] yeah, no problem [23:27] chrisccoulson: thanks [23:28] * micahg needs to subscribe to package to watch for regressions [23:29] bdrung_: can you look into the eclipse /path/to/xulrunner bug? [23:30] micahg: i will do it before the release [23:30] bdrung_: ok, thanks, just wanted to make sure someone was on it :) [23:31] micahg: the best solution would be an autodetection of xulrunner, but this does not work :( [23:31] bdrung_: what do you mean? [23:31] bdrung_: are you referring to the ini? [23:32] micahg: we have two places, where we have to set the xulrunner path. 1. eclipse script (LD_*) 2. eclipse.ini [23:33] bdrung_: can we consolidate everything in the script and then use xulrunner-1.9.2 --gre-version to do it dynamically? [23:34] micahg: that was my idea too, but there were some problem. [23:34] let's talk to nthykier [23:35] bdrung_: sure, when, where? [23:36] bdrung_: yo [23:36] hi nthykier [23:36] nthykier: we need a dynamical xulrunner path [23:36] therefore it can't be in eclipse.ini [23:36] yeah [23:36] what was the reason for not putting it into the script? [23:37] looks like we can implement a java class that eclipse will call if it is not given a path [23:37] nthykier: or fix upstream [23:37] bdrung_: because then we have to start parsing and understanding arguments which I would like to avoid - no arguments given per cmd by user = no cmd args at all [23:38] nthykier: because we have to change the order of the user args? [23:41] No, because I don't want to spend time debugging user problems that is caused by our script because we cause eclipse to ignore eclipse.ini since we passed it a (certain?) argument nor do I want to parse eclipse.ini and build the arguments + filter user supplied args. [23:43] I don't care if we patch the upstream java files or we implement our own "Xulrunner" locator class. [23:45] as long as we do not restore the horror that is the old eclipse wrapper ... [23:45] nthykier: i removed both xulrunner paths. the javadoc works - there the autodetection works, but the welcome page is not rendered correctly [23:45] how "many" xulrunners do you have? [23:46] one [23:46] Try adding a second. [23:46] let the fun begin [23:46] I am almost willing to put money on it crashing [23:46] still working [23:47] i won the money :D [23:47] read: almost [23:47] The only time xulrunner does not crash is when I need it too [23:47] bdrung_: which xul did you install? [23:48] xulrunner-1.9.2 and xulrunner-1.9.1 [23:48] bdrung_: try 193 :) [23:49] the internal browser does not work [23:49] No more handles [MOZILLA_FIVE_HOME='/usr/lib64/xulrunner-devel-1.9.2.3'] (java.lang.UnsatisfiedLinkError: no swt-mozilla-gtk-3557 or swt-mozilla-gtk in swt.library.path, java.library.path or the jar file) [23:49] org.eclipse.swt.SWTError: No more handles [MOZILLA_FIVE_HOME='/usr/lib64/xulrunner-devel-1.9.2.3'] (java.lang.UnsatisfiedLinkError: no swt-mozilla-gtk-3557 or swt-mozilla-gtk in swt.library.path, java.library.path or the jar file) [23:49] and if you set the xulrunner property? [23:49] bdrung_: are you using swt-gtk? [23:49] nope [23:50] micahg: eclipse uses its own copy of it [23:50] bdrung_: how does debian allow that? [23:51] pssst [23:51] micahg: send us a patch for building eclipse against swt-gtk ;) [23:51] swt-gtk is not compatiable with swt we build in eclispe [23:51] and also, it seems to remember the dev path from build time [23:51] build time? [23:52] probably because our swt is heavily patched [23:52] bdrung_: the -devel directory is where the headers are for building [23:52] nthykier: are you an eclipse dev? [23:52] the brokenness of umd is really getting in the way of my bug squashing [23:52] LLStarks: I hope you're testing with upstream builds for that text area bug [23:52] no usable xulrunner-1.9.3-dev [23:52] i am [23:53] but i can't compile upstream [23:53] because i don't have the proper build-deps [23:53] LLStarks: you shouldn't need our stuff to compile upstream [23:53] yeah i know [23:53] but i like apt-get build-dep firefox-3.7 [23:53] saves me a lot of trouble [23:53] micahg: No, I just co-maintainer the package [23:53] LLStarks: do apt-get build dep xulrunner-1.9.3 [23:54] nthykier: k [23:54] i did that yesterday, but i'm sure i'm still missing things [23:54] LLStarks: you can try apt-get build-dep firefox-3.6 [23:54] oops [23:54] apt-get build-dep firefox [23:55] nthykier: the eclipse package behaves the same (because the path is not correct any more) [23:55] how do i pull specific revs for hg? [23:55] i'm more of a git guy [23:55] LLStarks: hg bisect tool would probbaly be good [23:55] bdrung_: is our script capable of finding the correct version of xulrunner? [23:57] nthykier: what does the script/program do with the value in the ini? [23:58]