[02:20] <gnomefreak> asac: if your around, i know its a bit early for you to be here, however what standards on FTBFS would be upstream problem as opposed to local bug? [reed] if your here please feel free to give me some guide on how to tell upstream FTB or our FTB
[02:40] <asac> gnomefreak: depends
[02:41] <asac> gnomefreak: we should ensure its not a problem on our side before asking upstream to look into it
[02:41] <gnomefreak> asac: if iget time tomorrow i will try again
[02:52] <gnomefreak> ok grabbinb latest daily and going to bed im tired and cranky as hell
[07:06] <kaushal> hi
[07:06] <kaushal> when is Firefox 3.0.9 going to be added in Ubuntu 8.04 repository ?
[07:41] <kaushal> checking in again for my query :)
[09:00] <kaushal> hi again
[09:00] <kaushal> reposting my query here again, when is Firefox 3.0.9 going to be added in Ubuntu 8.04 repository ?
[09:28] <ghindo> kaushal: When it's added to the other Ubuntu repositories? :p
[09:28] <ghindo> kaushal: Probably not too long.  When was it released?
[09:33] <kaushal> http://www.mozilla.org/security/announce/2009/mfsa2009-14.html
[12:39] <directhex> guys, how do i go about debugging a plugin?
[12:40] <asac> directhex: plugin != extension
[12:40] <asac> what do you mean ;)
[12:40] <asac> kaushal: we wait 24h before releasing security updates
[12:40] <asac> kaushal: in that way we dont run into regressions and let mozilla catch them for us
[12:40] <directhex> asac, i said plugin!
[12:41] <asac> directhex: you never know ;)
[12:41] <asac> directhex: i guess you know that there is no general answer to that question, right?
[12:42] <directhex> asac, how do i set a breakpoint on a plugin with "firefox -g", since the plugin and its symbols aren't loaded until FF has been run?
[12:43] <asac> directhex: usually setting breakpoints up-front works
[12:43] <asac> directhex: if your plugin spawns a new process you need to tell gdb to follow that
[12:47] <directhex> 0x00007fdd8b7275a4 in MoonWindowGtk::InitializeFullScreen (this=Cannot access memory at address 0x7ffeffffffc8
[12:47] <directhex> ) at window-gtk.cpp:50
[12:47] <directhex> 50		GdkWindow *gdk = parent->GetGdkWindow ();
[12:47] <directhex> that's the best i've got from it so far
[12:52] <directhex> ooh, i got a breakpoint to break
[12:53] <directhex> hm, what a big backtrace
[12:55] <kaushal> asac: Thanks :)
[12:55] <directhex> http://pastebin.ca/1399539
[12:56] <kaushal> asac: I didnot understand about this line < asac> kaushal: in that way we dont run into regressions and let mozilla catch them for us
[12:56] <kaushal> give me examples :)
[12:56] <asac> kaushal: from time to time mozilla - after doing weeks of QA and stuff - release and suddenly something is broken
[12:56] <asac> thats a regression
[12:56] <asac> the worst regressions are usually detected quite quickly
[12:57] <asac> so waiting 24h is enough
[12:57] <asac> we released at the same minute in the past, but at some point there was a data loss regression
[12:57] <asac> and mozilla has a heavy weight QA process
[12:57] <asac> (which is good)
[12:57] <asac> so it took a couple of days again
[12:57] <asac> and we were not supposed to release a quick fix to our users without waiting for them
[12:58] <asac> thats why i dont release at the same time anymore and let them catch the bugs for us ... so i dont have to sit a week on a patch that would fix our users suffering, but not being allowed to distribute that
[12:58] <asac> (because of trademark stuff)
[13:00] <asac> kaushal: hope that explains it
[13:01] <kaushal> asac: awesome much appreciated :)
[13:01] <kaushal> asac: great and Thank you
[13:03] <asac> directhex: ;)
[13:03] <directhex> hm?
[13:03] <asac> directhex: referred to "what a big backtradce"
[13:03] <asac> directhex: so all figured?
[13:04] <kaushal> asac: we as in means "ubuntu" right ?
[13:04] <kaushal> or canonical ?
[13:05] <asac> kaushal: what part are you referring to?
[13:05] <kaushal> 17:10 #ubuntu-mozillateam: < asac> kaushal: we wait 24h before releasing security updates
[13:05] <asac> kaushal: thats ubuntu ... yeah
[13:05] <directhex> asac, working with upstream
[13:06] <asac> kaushal: but thats also kind of canonical ;)
[14:25] <directhex> asac, upstream reckons it's an ubuntu problem of some kind, and i reckon they're right.
[14:26] <directhex> asac, the problem doesn't occur with the .xpi download of the plugin
[15:22] <asac> directhex: thats not really much info you are giving ;)
[15:23] <directhex> giving it as i get it!
[16:11] <asac> directhex: you didn't tell me what the bug is about at all :)
[16:12] <directhex> asac, moonlight-plugin-mozilla causes browser crashing if you try to display a full-screen video (test site is http://videoshow.vertigo.com)
[16:12] <directhex> asac, happens with packages but not upstream .xpi, so it's something ubuntuish causing issues
[16:13] <asac> directhex: moonlight is in the archive?
[16:13] <directhex> asac, sure
[16:13] <asac> so they do stupid plugin guessing and dont trigger ubufox
[16:13] <asac> stupid folks
[16:13] <directhex> hm? who does?
[16:13] <asac> the website
[16:14] <asac> it should just display the embed/object thing
[16:14] <asac> and dont use a detection kit
[16:14] <directhex> ah. detection kitting is part of upstream Silverlight.js
[16:14] <asac> which is stupid
[16:14] <asac> ;)
[16:14] <directhex> i.e. blame microsoft for lack of plugin finder in msie for breaking it for everyone else ;)
[16:14] <asac> anyway. whats the package called then?
[16:14] <directhex> moonlight-plugin-mozilla, source package moon
[16:15] <asac> directhex: ok. installling. did you add our plugin meta data to control? (i think remember that you did that)
[16:15] <directhex> asac, yes, i don't know how correct it is of course :)
[16:17] <asac> yeah. we need the anti-plugin-detection-kit ;)
[16:19] <directhex> i'm testing in a 32-bit vm to see if it's 64-bit-related
[16:19] <asac> good idea
[16:19] <directhex> it is indeed a 64-bit problem
[16:20] <asac> good. so its upstream!!!
[16:21] <directhex> or a regression someplace else ;)
[16:31] <directhex> hm, possible fix from upstream. etsting...
[21:00] <jdhore1> Is there a estimated ETA for Firefox 3.0.9 hitting Hardy's repos?
[21:42] <directhex> asac, in case you were curious, upstream bug located & just dpatched. i'll SRU it for jaunty
[22:41] <asac> directhex: showing patch would entertain me ;)
[22:41] <asac> jdhore1: we release 24h after mozilla for various reasons
[22:41] <asac> so any minute
[22:41] <directhex> asac, http://svn.debian.org/viewsvn/pkg-mono/moon/trunk/debian/patches/moon_fix_gdk_pointer_size.dpatch?revision=3966&view=markup
[22:42] <asac> heh
[22:42] <asac> so undefined prototype somewhere?
[22:48] <directhex> something like that. gtk-2.0/gtk/gdktypes.h defines GdkNativeWindow as either gpointer or guint32 depending on whether GDK_NATIVE_WINDOW_POINTER is defined
[22:49] <directhex> GDK_NATIVE_WINDOW_POINTER is defined in moonlight.h depending on whether GLIB_SIZEOF_VOID_P is 8 (as it is on 64-bit platforms)
[22:50] <directhex> and GLIB_SIZEOF_VOID_P comes from glib.h
[22:50] <directhex> so... include glib.h then moonlight.h, and sizeof(GdkNativeWindow) is 8, otherwise it's 4
[22:51] <directhex> a fixed plugin will be landing in incoming.debian.org within minutes
[23:15] <asac> directhex: will you do a SRU for jaunty?
[23:15] <directhex> asac, need to do the paperwork, but yes, it's very much my intention
[23:37] <directhex> [ ]	moon_1.0.1-3.dsc	22-Apr-2009 22:32 	1.5K
[23:37] <BUGabundo> asac: hi
[23:37] <BUGabundo> asac: how to rebuild fontconfig cache?
[23:38] <asac> BUGabundo: fc-cache --system-only
[23:38] <asac> at least i think
[23:39] <asac> usually you dont need to do that, right?
[23:40] <BUGabundo> yeah
[23:40] <BUGabundo> but a user seems to have a corrupted cache
[23:40] <BUGabundo> http://img513.imageshack.us/img513/8053/capturaecra6.png
[23:41] <directhex> asac, assuming for a second that a silverlight site isn't using browser detection (it's true, some don't), would the moon package be picked up by ubufox as-is? or is extra work needed for the metadata i added to debian/control to be seen?
[23:41] <asac> directhex: havent checked.
[23:41] <asac> i would suggest to do a test site
[23:42] <asac> directhex: but form looking at control it looks right
[23:43] <directhex> asac, how does ubufox do the searches, i.e. where is the data it searches?
[23:44] <asac> directhex: what is a typical moonlight extension?
[23:44] <asac> file extension i mean
[23:44] <asac> .moon?
[23:44] <asac> err sl ;)
[23:45] <directhex> asac, erm..... for SL1? .js
[23:46] <asac> directhex: http://people.ubuntu.com/~asac/pfs/test/3_triplecontent.html
[23:46] <asac> directhex: unfortunately i have no file so you have to click on the tools -> manage content plugins
[23:46] <asac> and have to select search
[23:47] <asac> for silverlight mimetype
[23:47] <asac> thats what you would get if there would be real content with file
[23:48] <asac> description seems to be quite long
[23:49] <directhex> asac, patches welcome
[23:49] <asac> heh
[23:49] <directhex> asac, if it helps, i'll look at some dummy SL content for your page
[23:50] <asac> directhex: you sure you can use silverlight in the description?
[23:51] <asac> e.g. trademark
[23:51] <directhex> ehm... i'll look into that
[23:52] <asac> Xb-Npp-Description: The GNU SWF Player (http://www.gnu.org/software/gnash/)
[23:53] <asac> anyway. i think its ok except maybe the silverlight name
[23:53] <asac> ubufox should line break at some point
[23:56] <directhex> <object type="application/x-silverlight"
[23:56] <directhex> 	data="data:application/x-silverlight,"
[23:56] <directhex>        width="240"
[23:56] <directhex>        height="197"></object>
[23:56] <directhex> works for me. give it a punt
[23:57] <directhex> i extracted the actions taken by Silverlight.js when it inserts the <object> into the DOM
[23:57] <directhex> that cut-down version seems valid