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:20 |
---|---|---|
asac | gnomefreak: depends | 02:40 |
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:41 |
gnomefreak | ok grabbinb latest daily and going to bed im tired and cranky as hell | 02:52 |
=== jtv1 is now known as jtv | ||
kaushal | hi | 07:06 |
kaushal | when is Firefox 3.0.9 going to be added in Ubuntu 8.04 repository ? | 07:06 |
kaushal | checking in again for my query :) | 07:41 |
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:00 |
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:28 |
kaushal | http://www.mozilla.org/security/announce/2009/mfsa2009-14.html | 09:33 |
directhex | guys, how do i go about debugging a plugin? | 12:39 |
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:40 |
asac | directhex: you never know ;) | 12:41 |
asac | directhex: i guess you know that there is no general answer to that question, right? | 12:41 |
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:42 |
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:43 |
directhex | 0x00007fdd8b7275a4 in MoonWindowGtk::InitializeFullScreen (this=Cannot access memory at address 0x7ffeffffffc8 | 12:47 |
directhex | ) at window-gtk.cpp:50 | 12:47 |
directhex | 50GdkWindow *gdk = parent->GetGdkWindow (); | 12:47 |
directhex | that's the best i've got from it so far | 12:47 |
directhex | ooh, i got a breakpoint to break | 12:52 |
directhex | hm, what a big backtrace | 12:53 |
kaushal | asac: Thanks :) | 12:55 |
directhex | http://pastebin.ca/1399539 | 12:55 |
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:56 |
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:57 |
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) | 12:58 |
asac | kaushal: hope that explains it | 13:00 |
kaushal | asac: awesome much appreciated :) | 13:01 |
kaushal | asac: great and Thank you | 13:01 |
asac | directhex: ;) | 13:03 |
directhex | hm? | 13:03 |
asac | directhex: referred to "what a big backtradce" | 13:03 |
asac | directhex: so all figured? | 13:03 |
kaushal | asac: we as in means "ubuntu" right ? | 13:04 |
kaushal | or canonical ? | 13:04 |
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:05 |
asac | kaushal: but thats also kind of canonical ;) | 13:06 |
directhex | asac, upstream reckons it's an ubuntu problem of some kind, and i reckon they're right. | 14:25 |
directhex | asac, the problem doesn't occur with the .xpi download of the plugin | 14:26 |
asac | directhex: thats not really much info you are giving ;) | 15:22 |
directhex | giving it as i get it! | 15:23 |
asac | directhex: you didn't tell me what the bug is about at all :) | 16:11 |
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:12 |
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:13 |
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:14 |
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:15 |
asac | yeah. we need the anti-plugin-detection-kit ;) | 16:17 |
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:19 |
asac | good. so its upstream!!! | 16:20 |
directhex | or a regression someplace else ;) | 16:21 |
directhex | hm, possible fix from upstream. etsting... | 16:31 |
jdhore1 | Is there a estimated ETA for Firefox 3.0.9 hitting Hardy's repos? | 21:00 |
=== beDrung is now known as bdrung | ||
directhex | asac, in case you were curious, upstream bug located & just dpatched. i'll SRU it for jaunty | 21:42 |
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:41 |
asac | heh | 22:42 |
asac | so undefined prototype somewhere? | 22:42 |
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:48 |
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:49 |
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:50 |
directhex | a fixed plugin will be landing in incoming.debian.org within minutes | 22:51 |
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:15 |
directhex | [ ]moon_1.0.1-3.dsc22-Apr-2009 22:32 1.5K | 23:37 |
BUGabundo | asac: hi | 23:37 |
BUGabundo | asac: how to rebuild fontconfig cache? | 23:37 |
asac | BUGabundo: fc-cache --system-only | 23:38 |
asac | at least i think | 23:38 |
asac | usually you dont need to do that, right? | 23:39 |
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:40 |
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:41 |
asac | directhex: but form looking at control it looks right | 23:42 |
directhex | asac, how does ubufox do the searches, i.e. where is the data it searches? | 23:43 |
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:44 |
directhex | asac, erm..... for SL1? .js | 23:45 |
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:46 |
asac | for silverlight mimetype | 23:47 |
asac | thats what you would get if there would be real content with file | 23:47 |
asac | description seems to be quite long | 23:48 |
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:49 |
asac | directhex: you sure you can use silverlight in the description? | 23:50 |
asac | e.g. trademark | 23:51 |
directhex | ehm... i'll look into that | 23:51 |
asac | Xb-Npp-Description: The GNU SWF Player (http://www.gnu.org/software/gnash/) | 23:52 |
asac | anyway. i think its ok except maybe the silverlight name | 23:53 |
asac | ubufox should line break at some point | 23:53 |
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:56 |
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 | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!