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