=== JanC_ is now known as JanC
[06:39] <Brownout> grrrr, Sync nagging for the master password is annoying as hell
[10:24] <silvery> Hello, everyone. Please tell me, how can I update Firefox version in Ubuntu, without having 2 versions on my desktop? (I tried original overlay and now I have both 3.smth.smth and 4b8 installed)
[10:25] <silvery> + I have to run './firefox &' to run my 4b8
[10:25] <silvery> ping
=== micahg changed the topic of #ubuntu-mozillateam to: Welcome to the Ubuntu Mozilla Team (Chromium too!): | Firefox 4.0b9 in Firefox Beta PPA 9.10-10.10 http://is.gd/f6TM4 | Nothing in http://is.gd/dsudW needs testing | Firefox 3.6.13 in Hardy-Maverick | Thunderbird 3.1.7 in Lucid-Natty and Stable PPA | Report Mozilla PPA bugs here: http://is.gd/hdZc1
[15:48] <kimus> Hi, i'm using the latest fx4 from ppa. and I filled this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=626417
[15:48] <ubot2> Mozilla bug 626417 in General "XML files with XSL Stylesheet" [Major,Unconfirmed]
[15:48] <kimus> anyone has a problem with this or knows how to fix it? thanks
[15:49] <micahg> kimus: do you have a DTD for xml-stylesheet?
[15:49] <kimus> hi micahg, It always worked on all browsers :-)
[15:51] <kimus> micahg: the stylesheet does not have any special elements on it
[15:51] <kimus> micahg: and the xml file has the DOCTYPE svn (explaining the svn xml elements returend)
[15:52] <kimus> and yes this is a SVN repo... but I can test locally in my pc
[15:54] <kimus> locally does not work either...
[15:55] <kimus> I will attach the xml and xsl
[15:56] <micahg> kimus: I'm sorry, I'm not that familiar with XSL, but yes, a test document would help
[15:56] <micahg> kimus: I've subscribed to the bug so I can watch its progress
[15:58] <kimus> micahg: you can download the xml and xsl file and open the xml in the browser
[15:58] <kimus> it should render a html file
[15:59] <micahg> kimus: I can try a little later, I have to go somewhere soon
[19:54] <fta> cyphermox, seems you committed some merge conflicts in network-manager-applet d/changelog
[19:55] <cyphermox> fta?
[19:55] <cyphermox> I fixed it as I did the merge
[19:55] <cyphermox> I don't know why it ended up as a conflict since I always take from the ubuntu.head branches before doing changes, but oh well
[19:56] <fta> cyphermox, got an email for the merge request including this: http://paste.ubuntu.com/555189/
[19:57] <cyphermox> fta, right yeah... I fixed that as I did the merge
[19:57] <cyphermox> sorry for the noise ;)
[19:58] <fta> n-p
[19:58] <cyphermox> nm-applet now with more ipv6 love too
[20:12] <fta> great
[20:12] <fta> i wish i had ipv6 at home
[20:14] <fta> chrisccoulson, transmission is freezing.. libdebusmenu something. is that another side effect of the unfinished transition from last week?
[20:14] <fta> i mean, libdbusmenu
[20:15] <chrisccoulson> fta - the transition is done, but there's a fair amount of things that are broken
[20:15] <chrisccoulson> could you get a backtrace of it when its frozen?
[20:15] <chrisccoulson> i'm currently investigating other breakage related to the transition
[20:16] <fta> (transmission-gtk:10429): GLib-GObject-WARNING **: cannot register existing type `DbusmenuMenuitem'
[20:16] <fta> (transmission-gtk:10429): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
[20:16] <fta> (transmission-gtk:10429): LIBDBUSMENU-GLIB-CRITICAL **: dbusmenu_menuitem_property_set_variant: assertion `DBUSMENU_IS_MENUITEM(mi)' failed
[20:16] <fta> that's when i start it
[20:16] <fta> i don't have the -gdb for a trace
[20:17] <chrisccoulson> is that the first warning you get?
[20:17] <chrisccoulson> might be worth running in GDB with G_DEBUG=fatal_warnings
[20:17] <fta> #3  0x016d5938 in dbusmenu_menuitem_get_type () from /usr/lib/libdbusmenu-glib.so.3
[20:17] <fta> #4  0x016d661f in dbusmenu_menuitem_property_set_variant () from /usr/lib/libdbusmenu-glib.so.3
[20:17] <fta> #5  0x016ceb4e in dbusmenu_menuitem_property_set_shortcut () from /usr/lib/libdbusmenu-gtk.so.3
[20:17] <fta> #6  0x016cee48 in dbusmenu_menuitem_property_set_shortcut_menuitem () from /usr/lib/libdbusmenu-gtk.so.3
[20:17] <fta> #7  0x016c2e3f in ?? () from /usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so
[20:18] <chrisccoulson> is that where it hangs?
[20:18] <fta> that's when i interrupt it
[20:19] <chrisccoulson> might be worth running with G_DEBUG=fatal_warnings, to see where it starts to go wrong
[20:19] <fta> GLib-GObject-WARNING **: cannot register existing type `DbusmenuMenuitem'
[20:19] <fta> aborting...
[20:19] <fta> Program received signal SIGTRAP, Trace/breakpoint trap.
[20:19] <fta> g_logv (log_domain=0x82bded "GLib-GObject", log_level=<value optimized out>, format=0x832b18 "cannot register existing type `%s'", args1=0xbfffe68c "k\205", <incomplete sequence \337>)
[20:19] <fta>     at /build/buildd/glib2.0-2.27.91/glib/gmessages.c:563
[20:20] <fta> hold on, i'll install some dbg(sym)
[20:23] <fta> chrisccoulson, http://paste.ubuntu.com/555196/
[20:24] <fta> want more?
[20:37] <chrisccoulson> fta - sorry, i had to go away for some dinner?
[20:37] <chrisccoulson> have you got a longer trace where the warning occurs?
[20:40] <fta> chrisccoulson, http://paste.ubuntu.com/555208/ ?
[20:41] <chrisccoulson> fta - is transmission pulling 2 versions of libdbusmenu-glib in to memory?
[20:41] <chrisccoulson> i think that's the only way that could happen
[20:41] <chrisccoulson> (ie, 1 of each ABI version)
[20:42] <fta> $ ldd /usr/bin/transmission-gtk  | grep menu
[20:42] <fta>         libdbusmenu-glib.so.2 => /usr/lib/libdbusmenu-glib.so.2 (0x00713000)
[20:42] <fta> or is it dlopened?
[20:42] <fta> weird
[20:43] <chrisccoulson> fta - oh, have you not updated transmission yet?
[20:43] <chrisccoulson> it's linking against -glib2, whereas -glib3 gets pulled in to memory via the updated indicator stack
[20:43] <chrisccoulson> i guess that's the issue
[20:44] <fta> i have a bunch of un-upgradable packages, hence i said unfinished transition earlier
[20:44] <chrisccoulson> i have 2.13-0ubuntu1, and it links against libdbusmenu-glib.so.3
[20:44] <chrisccoulson> hmmm, i've managed to upgrade everything now :/
[20:45] <fta> retrying then...
[20:45] <chrisccoulson> yeah, that should resolve it, assuming apt manages to resolve it ok ;)
[20:47] <fta> The following packages will be REMOVED:
[20:47] <fta>   libindicator1 libunity0 libwebkit-1.0-2 libwebkit-1.0-common midori unity-place-applications unity-place-files
[20:47] <fta> are the last 3 expected?
[20:48] <fta> 39 upgraded, 5 newly installed, 7 to remove and 0 not upgraded.
[20:48] <fta> should do it
[20:51] <chrisccoulson> yeah, those can all be removed
[20:51] <chrisccoulson> i'm just wondering why transmission links directly with libdbusmenu. that seems wrong
[20:52] <chrisccoulson> it's using libappindicator though
[20:52] <fta> \o/ works now
[20:52] <fta> but the indicator is broken
[20:52] <fta> maybe i should kill the panel
[20:53] <chrisccoulson> yeah, you could try that
[20:54] <chrisccoulson> the new indicator stack is pretty broken though. see bug 703689 and bug 703769
[20:54] <ubot2> Launchpad bug 703689 in indicator-appmenu (Ubuntu) (and 1 other project) "Window registration racy with GDbus port (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/703689
[20:54] <ubot2> Launchpad bug 703769 in indicator-appmenu (Ubuntu) (and 1 other project) "Menus are not destroyed when a window is closed with GDbus port (affects: 1) (heat: 6)" [Medium,New] https://launchpad.net/bugs/703769
[20:54] <fta> booohouuhh
[20:55] <chrisccoulson> and the messaging menu seems to be completely broken too
[20:56] <fta> liferea and rhythmbox are back in the systray
[20:56] <fta> they are in the appmenu too
[20:57] <chrisccoulson> i remember ted saying last week that liferea needed some porting to make it work properly again. not sure if that happened yet though
[20:58] <chrisccoulson> i haven't tried liferea or rhythmbox yet
[21:23] <kimus> micahg: hi. did you see the Bug 626417?
[21:24] <micahg> kimus: yes, I don't have time to look right now as I"m at work, but can look later tonight
[21:24]  * micahg wonders why ubot2 is not producing an LP bug link
[21:24] <kimus> micahg: that's fine. I accomplish to filter the problem
[21:25] <micahg> kimus: thank you for that!
[21:25] <kimus> micahg: it's very strange :-)
[21:26] <kimus> I don't understand what the Tab Group could cause a transformation problem... strange...
[21:27] <micahg> kimus: the only thing I can think of is if it's overriding some other functionality, but I'll at least to try to confirm the bug tonight
[21:28] <kimus> micahg: thank you... for me it's a major bug :-)
[21:39] <BUGabundo> olá
[21:54] <kimus> BUGabundo:olá
[22:22] <fta> chrisccoulson, do you know anything about gtk_window_set_has_resize_grip() ?
[22:22] <chrisccoulson> fta - yeah, it's a feature we've backported from gtk3
[22:23] <chrisccoulson> we need to disable the resize grips on some windows, where they either shouldn't be displayed or cause other problems
[22:23] <fta> chrisccoulson, which ones of our distros has it?
[22:23] <chrisccoulson> fta - just natty
[22:23] <fta> damn
[22:23] <fta> bug 703451
[22:23] <ubot2> Launchpad bug 703451 in chromium-browser (Ubuntu) "Resize grips are covering scrollbar button on Chromium (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/703451
[22:24] <chrisccoulson> the same issue exists in firefox
[22:24] <chrisccoulson> but i'm not sure about disabling the resize grips
[22:24] <chrisccoulson> whilst ehy do partially obscure the lower scrollbar button, they don't make it unusable
[22:24] <chrisccoulson> but removing the resize grips makes it impossible to resize the window, now we have a 0-pixel border
[22:24] <chrisccoulson> i think that's worse....
[22:25] <fta> in chromium, it's unusable
[22:25] <chrisccoulson> resizing or the scrollbar button?
[22:25] <fta> sb button
[22:25] <fta> there's an ugly orange square
[22:25] <fta> on top
[22:25] <chrisccoulson> hmm, that's not good
[22:26] <fta> there's a patch in the bug, to disable it
[22:26] <fta> but it's not portable, so for the ppa, i need to do something smart
[22:27] <fta> maybe a dh_quilt_dist tweaking the series file according to the current dist
[22:28] <chrisccoulson> fta - it doesn't use autoconf does it? it's relatively easy to add a configure check in that case
[22:28] <fta> nope