[00:00] <kklimonda> why is desktop-bugs ML inactive?
[00:00] <kklimonda> hmm.. it isn't
[00:01] <kklimonda> I wonder why don't I see new posts neither on gmane nor https://lists.ubuntu.com/archives/desktop-bugs/
[00:06] <seb128_> the archive are not on for bugs list
[00:06] <seb128_> too many informations and nobody going to browse that online
[00:09] <kklimonda> seb128_: I was planning to use news client to get info about new bugs (and read MLs) so I can declutter my mail box :)
[00:11] <seb128_> no luck for you then
[00:11] <seb128_> 'night everything
[00:11] <kklimonda> but if new bugs are sent to desktop-bugs ML then they should be available from gmane..
[02:57] <jcastro> bratsche, wait, you're the guy who fixed bgo:56070? Man, if I would have known that I would have bought you a steak dinner.
[02:59] <bratsche> jcastro: Hey dude!  How's it going?
[02:59] <jcastro> good, I just wandered across your page on the wiki
[02:59] <bratsche> jcastro: Dude, I ordered an Intel X25-M now after I saw yours in action.
[03:00] <jcastro> hah
[03:00] <jcastro> they just started reshipping the new ones right?
[03:01] <bratsche> I'm not sure.
[03:02] <bratsche> I can't wait, I'm so excited.
[03:02] <jcastro> heh
[03:03] <jcastro> check these out dude: http://www.fusionio.com/Products.aspx
[03:05] <bratsche> Oh hot!
[03:24] <bratsche> jcastro: Whoa.. I just noticed the price tag on that.  80gig for $895?  heh.
[08:26] <chrisccoulson> hey seb128
[08:26] <seb128> hey chrisccoulson
[08:36] <chrisccoulson> i bet you're looking forward to your holiday now seb128:)
[08:36] <seb128> chrisccoulson, yes ;-)
[08:37] <seb128> the week has been ok but still I didn't take much days off this year
[08:37] <seb128> so it will be good to have a computer break
[08:37] <chrisccoulson> yeah, you're always here ;)
[08:37] <seb128> I will try to be good at not working during those
[08:38] <chrisccoulson> yes, you should have a proper rest ;)
[08:39] <chrisccoulson> right, i have to disappear, i'm working away off site today
[08:39] <seb128> chrisccoulson, good luck
[08:39] <seb128> is that better than "have fun"? ;-)
[08:39] <chrisccoulson> thanks. have a good day :)
[09:14] <huats> morning everyone
[09:15] <seb128> lut huats
[09:16] <huats> hello seb128
[10:11] <didrocks> morning everyone o/
[10:11] <seb128> lut didrocks
[10:11] <seb128> didrocks, ca va ?
[10:11] <didrocks> hey seb128! Oui oui, ça va, toujours comme le temps qui est magnifique :)
[10:11] <didrocks> seb128: et toi ?
[10:11] <seb128> ca va bien
[10:12] <seb128> le temps est gris ici
[10:12] <seb128> ca me va pour bosser
[10:12] <didrocks> oui, quand il fait trop chaud, bosser devient difficile :)
[10:22] <seb128> jcastro, hello
[10:22] <seb128> jcastro, could you add gnome-disk-utility to launchpad?
[10:22] <seb128> so we can add upstream tasks
[10:29] <davmor2> Outta curiosity is there a reason why a new instance of evolution is open when you click on a date in the panel calendar, this is when you have  evo open for email
[10:30] <davmor2> in fact I just check it does it if you click on 2 different dates in the calendar
[10:37] <seb128> it's not a new instance
[10:37] <seb128> it's a new view
[10:37] <seb128> and yes, clicking on a calendar doesn't mean you want to switch away from the email you were reading
[10:37] <seb128> it's a non disruptive behaviour
[10:38] <asac> hey. yesterday i rebooted and had hoped for parts of the new boot experience. did anything of that already land?
[10:39] <asac> do i need to do something? like upgrading to grub2?
[10:39] <seb128> asac, you should have get usplash running
[10:39] <seb128> xsplash I mean
[10:39] <asac> seb128: how would i see?
[10:40] <seb128> do you have a custom background?
[10:40] <seb128> autologin on?
[10:40] <asac> xsplash is not installed ;)
[10:40] <seb128> ok, so you don't ubuntu-desktop installed?
[10:40] <asac> let me install ubuntu-desktop and see if that got removed again
[10:40] <seb128> +have
[10:40] <seb128> what got removed?
[10:40] <asac> also for about 2 years i am seeing the kubuntu splash screen ;)
[10:40] <asac> seb128: ubuntu-desktop
[10:41] <asac> ok now i have xsplash 0.4 ;)
[10:41] <seb128> need to restart my session, e-d-s crashed or something
[10:41] <seb128> and that frozen my gnome-panel
[10:41] <seb128> can't start evo now
[10:41] <asac> heh
[10:44] <seb128> re
[10:44] <seb128> better now
[10:47] <davmor2> seb128: thanks for explaining :)
[10:47] <seb128> asac, it's not really fancy now
[10:47] <seb128> ie still flickering
[10:47] <seb128> and it's confusing if you use a different image
[10:51] <asac> seb128: how can i reset everything splash related?
[10:51] <seb128> reset?
[10:51] <asac> seb128: as i said i am seeing the "Kubuntu" start thing for about 2 years now ;)
[10:51] <seb128> ah
[10:51] <asac> i guess there is an alternative or something ;)
[10:52] <seb128> asac, gconftool-2 --unset /apps/gnome-session/options/splash_image
[10:52] <seb128> asac, gconftool-2 --unset /apps/gnome-session/op
[10:52] <seb128> op
[10:53] <seb128> asac, gconftool-2 --unset /apps/gnome-session/options/show_splash_screen
[10:53] <asac> seb128: i dont think the kubuntu thing i am seeing is gnome-session related.
[10:53] <seb128> we default at not showing splashes nowadays
[10:53] <asac> its what i get after grub
[10:53] <seb128> ah
[10:53] <asac> anyway running those commands now. they cannot hurt ;)
[10:54] <seb128> asac, $ update-alternatives --display usplash-artwork.so
[10:55] <asac> yay
[10:55] <asac> thats it
[10:55] <asac> /usr/lib/usplash/usplash-theme-kubuntu.so - priority 55
[10:55] <asac> /usr/lib/usplash/usplash-theme-ubuntu.so - priority 10
[10:55] <asac> /usr/lib/usplash/usplash-theme-xubuntu.so - priority 10
[10:55] <asac> kubuntu is rude ;)
[10:56] <asac> prio 55
[10:56] <asac> good bye kubuntu start screen ;)
[10:56] <asac> thx
[10:59] <seb128> asac, np
[11:37] <seb128> soren, your g-c-c bugs seems not really a bug
[11:37] <seb128> soren, ie don't set virtual setting if you think those are broken
[11:38] <soren> seb128: Err... gnome-display-properties sets that for me.
[11:38] <soren> And gives me no way to revert it.
[11:39] <seb128> well there is no way to know why it has been set
[11:39] <seb128> could be for a good reason
[11:39] <seb128> in which case you don't want an option to unset it there
[11:39] <soren> So what do you suggest?
[11:40] <seb128> I would suggest that the display capplet should never play with virtual
[11:40] <seb128> and xorg should do the right thing
[11:40] <james_w> the thing that sets virtual could set it to max(needed virtual for configuration, maximum possible screen resolution)
[11:40] <soren> Fact of the matter is that users can paint themselves into a corner with no way to get back out (short of "sudo rm /etc/X11/xorg.conf")
[11:40] <james_w> then virtual would never restrict the screen resolution options
[11:40] <seb128> that's rather a screen-resolution-extra issue then
[11:40] <james_w> yep
[11:40] <james_w> assuming that's what happened
[11:41] <soren> james_w: Well... You can't really do that, since you don't know if the user is going to plug in an external screen with an even higher resolution later on.
[11:42] <james_w> true
[11:42] <james_w> that's a limitation of X though
[11:42] <soren> james_w: I guess a fix would be to let XRANDR report resolutions that it can't actually set, and then let gnome-control-center fiddle with virtual so that it'll fit.
[11:42] <soren> Since that's basically what it does already (when no virtual size is set).
[11:42] <james_w> that could work as well
[11:42] <soren> AFAIUI, anyways.
[11:42] <seb128> having to tweak virtual sucks
[11:43] <soren> It does, yes.
[11:43] <james_w> tseliot is the person that knows most about this
[11:43] <seb128> xorg should just be working
[11:43] <seb128> assigning the bug to him since he wrote those changes
[11:43] <soren> To be brutally honest, I don't really care much about the bug. I just helped a dude get out of it, and wanted to make sure the bug was filed.
[11:45] <tseliot> seb128: what bug is that?
[11:45] <soren> The problem is valid. The suggested root cause or fix or whatever, perhaps not. :)
[11:45] <seb128> tseliot, bug #412948
[11:46] <seb128> soren, speaking about bugs do you still work on vm-builder etc?
[11:46] <soren> seb128: In theory, yes.
[11:46] <soren> seb128: I've been on holiday or at conferences for the past month and a half, so I've had little or no time to do anything VMBuilder related.
[11:46] <seb128> soren, there is some sponsoring bugs waiting for ages
[11:47] <seb128> soren, if you could have a look at some point I'm sure dholbach would hug you
[11:48] <soren> seb128: I have every intention of going through all of that as soon as I have just a tiny bit of time. :)
[11:48] <seb128> soren, ok thanks ;-)
[11:49] <tseliot> seb128, soren: would it be ok if g-c-c set the virtual resolution to 2048x2048 (which shouldn't break direct rendering) unless something bigger is required?
[11:49] <seb128> I guess so
[11:50] <tseliot> only some intel cards and ati cards can handle >2048
[11:50] <seb128> it would limit the buggy cases probability
[11:50]  * tseliot nods
[11:51] <soren> tseliot: IIRC, we don't do that for a reason.
[11:51] <soren> tseliot: The reason could be any of the following:
[11:52] <soren> tseliot: To avoid making X reserve a whole bunch of RAM that it'll never need anyway.
[11:52] <soren> tseliot: Or because compiz doesn't work when the virtual screen is so big.
[11:52] <Amaranth> compiz will work with 2048x2048
[11:52] <soren> tseliot: I seem to have heard both reasons, but I'm not sure which (if any) is valid.
[11:52] <Amaranth> of course shatter will fix all of this...
[11:52] <Amaranth> whenever that comes
[11:52] <soren> shatter?
[11:53] <soren> Is that like damage?
[11:53] <tseliot> soren: things work differently with intel + UXA now. It can dynamically resize the frontbuffer
[11:53] <Amaranth> soren: it's a rework of the framebuffer setup in xorg
[11:53] <Amaranth> soren: ajax has been working on it off and on for years
[11:53] <soren> tseliot: Ah. right, my brain is probably outdated.
[11:53] <tseliot> soren: and direct rendering (hence Compiz) is not broken with 2048x2048
[11:53] <tseliot> ok
[11:54] <lool> kenvandine: I dont quite understand why you redid the xsplash packaging changes instead of just merging the branch, but it seems all is in so I closed the merge request
[11:54] <tseliot> last time I tried this with my intel card I wasn't even asked to set the virtual resolution
[12:02] <davmor2> seb128: did easy codec get added to rhythmbox too I can't remember?
[12:02] <seb128> yes
[12:02] <seb128> and that works on current iso I just tried
[12:02] <davmor2> seb128: Ah okay cool that's what I was going to do :)
[12:03] <seb128> the totem one is broken
[12:03] <seb128> known issue
[12:03] <seb128> lunch time bbl
[12:30] <asac> Riddell: you should add your canonical.com address to launchpad :)
[12:30] <asac> in that way you wouldnt show up as a random guy on code hosting ;)
[12:30] <asac> https://code.edge.launchpad.net/~network-manager/network-manager/ubuntu.head
[12:37] <Riddell> mm, good idea
[12:53] <seb128> slomo, hey
[12:57] <kklimonda> seb128: wrt bug 412808 - is it worth to push it upstream if I can't reproduce it with --sync ?
[12:57] <seb128> yes
[12:58] <seb128> they might have a better clue how to debug
[12:58] <seb128> or about what is going on
[12:58] <seb128> it's going to stay there for ever otherwise
[13:01] <seb128> slomo, is easy codec install working in totem debian?
[13:04] <slomo> seb128: i don't know, there's no reason why it shouldn't work ;) why?
[13:05] <seb128> slomo, http://bugzilla.gnome.org/show_bug.cgi?id=591677
[13:06] <slomo> seb128: ok, so definitely a totem problem... since when? 2.27.1 or .2?
[13:06] <seb128> slomo, I just noticed with current version
[13:06] <seb128> I'm not sure if 2.27.1 had the issue, I don't test every day
[13:06] <seb128> can you confirm on debian too?
[13:08] <slomo> seb128: hm, for me it just complains that a decoder is missing but not installed
[13:08] <slomo> but it doesn't launch the codec installer
[13:09] <seb128> slomo, ok, here I get the data flow error
[13:13] <slomo> seb128: yes, totem is broken... bacon-video-widget-gst-0.10.c:1565:bvw_check_missing_plugins_error: no missing-plugin messages
[13:13] <slomo> although there is
[13:15] <seb128> slomo, ok thanks, want to comment on the upstream bug?
[13:15] <slomo> already done
[13:15] <seb128> thanks!
[13:15] <slomo> i fear that i broke it while adding support for mounting gio locations because that works similar
[13:17] <seb128> slomo, I can test easily with 2.27.1 if you want
[13:17] <slomo> seb128: that'd be great :)
[13:26] <seb128> slomo, was broken there too
[13:27] <seb128> slomo, works with 2.26.2
[13:27] <MDC2> vuntz, is screen->priv->workpsace_type really necessary?
[13:28] <slomo> seb128: thanks, then i have no idea what could be the reason without looking at the code :)
[13:32] <vuntz> MDC2: you know you're asking something about a patch that is 1.5 years old ;-)
[13:32] <MDC2> vuntz, yeah i know.. sorry..
[13:32] <vuntz> MDC2: I think it was there only to have a cache; easier than recomputing things every time
[13:33] <vuntz> MDC2: but feel free to do things in a different way
[13:33] <MDC2> vuntz, but isnt it possible to have both workspaces and viewports in the same wm?
[13:33] <MDC2> vuntz, i'll hack something up.. at least it compiles now :)
[13:35] <vuntz> MDC2: yep, it's possible
[13:35] <vuntz> MDC2: but in that case, libwnck will just handle the real virtual desktops
[13:36] <vuntz> MDC2: at least, that's my opinion
[13:36] <vuntz> MDC2: anybody using viewport to implement workspaces inside virtual desktops is a weid user
[13:36] <vuntz> weird
[13:37] <vuntz> and I don't feel it's worth making things more complex for this 0.01% use case
[13:38] <Amaranth> No one should ever use both at the same time
[13:38] <Amaranth> afaik compiz is the only WM in active usage that uses viewports and at least in ubuntu we completely disable using virtual desktops at the same time
[13:39] <MDC2> vuntz, well i guess they are, I'll see how I'll implement it (taking the easiest path). But if I'm right, you'd like to have virtual desktop as an umbrella for all sort of crazy workspace, viewports things out there, and the "high level" api will just use that, but you could also get "low level" stuff such as what real wm workspace am i sitting on.. right?
[13:39] <MDC2> Amaranth, kwin uses workspaces?
[13:39] <Amaranth> MDC2: Actually Workspace is the high level and virtual desktop/viewport is the low level but yeah
[13:39] <Amaranth> MDC2: last time I checked it seemed to
[13:40] <Amaranth> although, again, workspaces is the wrong term because it can apply to both :P
[13:40] <MDC2> Amaranth, oh.. did you mean vuntz 1.5 year old dusty patch?
[13:41] <MDC2> if so.. crap. ;-)
[13:42] <vuntz> MDC2: no
[13:42] <vuntz> MDC2: virtual desktop is the technical term for the "real" workspace
[13:42] <vuntz> MDC2: so the low level is virtual desktop or viewport
[13:42] <vuntz> MDC2: high-level is workspace
[13:42] <MDC2> vuntz, damnit ;-) haha.. ok thanks..
[13:43] <seb128> vuntz, do you still use the modified gnome-session dialog in opensuse?
[13:43] <seb128> vuntz, is the srpm or patch online somewhere?
[13:44] <vuntz> seb128: tmp.vuntz.net/opensuse-packages/browse.py
[13:44] <vuntz> you should bookmark it :-)
[13:45] <seb128> vuntz, thanks
[13:53] <seb128> vuntz, you stopped using the custom dialog?
[13:55] <vuntz> seb128: no
[13:56] <seb128> hum
[13:56] <seb128> oh, it's tile_ui
[13:57] <seb128> confusing title
[13:57] <james_w> seb128: why did you think bug 403192 was in gdu?
[13:57] <seb128> james_w, because it crashes in gdu_something?
[13:57] <james_w> ok
[13:57] <james_w> it's using a NULL pool though
[13:57] <seb128> james_w,  #0 0x00135b5e in gdu_pool_get_devices () from /usr/lib/libgdu.so.0
[13:58] <seb128> which is libgdu
[13:58] <seb128> which is g-d-u
[13:58] <seb128> james_w, you think the bug is somewhere else?
[13:58] <james_w> update-notifier
[13:58] <seb128> james_w, why?
[13:58] <james_w> (and the same bug in gdu-notifier
[13:58] <james_w> )
[13:58] <tseliot> seb128, soren: screen-resolution-extra should work better now. A debdiff is available so that we can upload it after the freeze
[13:58] <james_w> because it's not checking the return from gdu_pool_new()
[13:59] <seb128> james_w, note that there is dups from other apps
[13:59] <seb128> oh ok
[13:59] <seb128> good ;-)
[13:59] <seb128> I didn't try to investigate, just cleaned g-d-u bugs
[13:59] <james_w> sure
[14:00] <james_w> just wondered if I missed something
[14:00] <seb128> no, I just did triaging
[14:00] <seb128> not debugging
[14:00] <seb128> thanks for looking into the issue!
[14:00] <james_w> if it can't connect to system dbus for example then it will return NULL
[14:00] <james_w> not sure what update-notifier should do in that situation
[14:01] <james_w> also "Couldn't get daemon properties" and "Couldn't enumerate devices:"
[14:02] <seb128> hum, not sure either
[14:02] <seb128> I guess you are screwed if you can't connect to dbus anyway
[14:02] <seb128> just exit with an error?
[14:03] <chrisccoulson> hello everyone
[14:04] <james_w> hey chrisccoulson
[14:04] <chrisccoulson> hey james_w. how are you?
[14:04] <james_w> good thanks
[14:04] <james_w> how are you?
[14:04] <seb128> hey chrisccoulson
[14:04] <james_w> http://paste.ubuntu.com/252490/ would be my proposed patch for the same issue in the gdu notification
[14:05] <chrisccoulson> hey seb128:)
[14:05] <chrisccoulson> james_w - i'm good thanks. i just arrived back at work and realised i've ran out of coffee though
[14:05] <chrisccoulson> so that's not so good ;)
[14:06] <seb128> vuntz, ok, you have the same bug that we have there (ie you didn't fix it)
[14:06] <seb128> vuntz,  _h used for both hibernated and help there
[14:07] <vuntz> possibly
[14:07] <vuntz> here, I have _Hiberner and _Aide ;-)
[14:07] <seb128> ;-)
[14:17] <chrisccoulson> seb128 - i'm really confused about bug 409621
[14:17] <seb128> chrisccoulson, why?
[14:17] <chrisccoulson> the reporter says that disabling the keyboard plugin stops the crash
[14:17] <chrisccoulson> but the trace with the --sync option suggests an issue with the xrandr plugin doesn't it?
[14:18] <chrisccoulson> unless i'm misunderstanding something
[14:18] <seb128> the issue is a xrandr not available one
[14:18] <chrisccoulson> yeah, it seems possible
[14:18] <seb128> I guess that libxklavier set the handler which catch the crash
[14:19] <seb128> all the g-s-d crashes tend to be confusing ones in xkl
[14:19] <seb128> I think that's because libxklavier has some code to catch exceptions
[14:19] <chrisccoulson> possibly. when it involves anything to do with Xorg, then I get confused;)
[14:20] <seb128> libgnomedesktop uses         gdk_error_trap_push ();
[14:22] <chrisccoulson> seb128 - should that not stop the application from exiting?
[14:23] <seb128> it should
[14:23] <seb128> I'm wondering if the libxklavier handling doesn't break things
[14:23] <chrisccoulson> maybe
[14:23] <chrisccoulson> i saw a gsd crash when i logged in yesterday too, but i couldn't recreate it again
[14:23] <chrisccoulson> and that was an untrapped X error too
[14:24] <chrisccoulson> i'm wondering if i should start always running g-s-d with --sync for a while just in case it happens again
[14:26] <seb128> chrisccoulson, do you want to upstream the bug?
[14:26] <seb128> it has enough details for that now
[14:26] <chrisccoulson> seb128 - yeah, can do. do you mind if i do it when i finish work though?
[14:27] <seb128> chrisccoulson, sure no hurry
[14:27] <chrisccoulson> cool:)
[14:27] <seb128> I don't really understand it either
[14:27] <chrisccoulson> it's difficult to do things without my employer noticing ;)
[14:27] <seb128> "	if (gdk_error_trap_pop ()) {
[14:27] <seb128> 	    g_set_error (error, GNOME_RR_ERROR, GNOME_RR_ERROR_UNKNOWN,
[14:27] <seb128> 			 _("unhandled X error while getting the range of screen sizes"));
[14:27] <seb128> 	    return FALSE;"
[14:27] <seb128> that should catch the error
[14:28] <seb128> oh in fact that's the error he gets
[14:28] <chrisccoulson> it should. i don't understand what happens inside XRRGetScreenSizeRange though
[14:28] <chrisccoulson> does that block?
[14:29] <chrisccoulson> it must do i suppose
[14:29] <seb128> no, I guess the nxserver doesn't handle that call
[14:30] <seb128> but that should not make gsd crash since it's trapping xorg errors
[14:30] <chrisccoulson> yeah, it seems strange. and the interaction with the keyboard plugin is wierd too
[14:31] <seb128> well as said g-s-d crashes to be confusing
[14:31] <seb128> libxklavier does something which makes it catch crashes evening if they come from other codepart there
[14:36] <seb128> chrisccoulson, http://bugzilla.gnome.org/show_bug.cgi?id=583709 seems similar
[14:37] <seb128> comment #16
[14:52] <rodrigo_> seb128: any news on http://revu.ubuntuwire.com/p/evolution-couchdb? I submitted a new package with the latest fixes and jonathan riddel was going to take it from my ppa, but had no news till now
[14:52] <seb128> rodrigo_, weird pitti said he did upload
[14:53] <rodrigo_> ah
[14:53] <seb128> did you get it rejected for some reason?
[14:53] <seb128> it's not in the queue
[14:53] <rodrigo_> no, no news since Dublin
[14:53] <seb128> Riddell, ^ did you upload that one?
[14:53] <rodrigo_> ah, didn't see Riddell around
[14:53] <Riddell> no, I spoke to rodrigo_ on the last day of dublin as he was leaving and he said it hadn't appeared on revu
[14:54] <rodrigo_> Riddell: I submitted the package to my ppa, as we discussed
[14:54] <Riddell> but didn't hear anything since
[14:54] <Laney> rodrigo_: please specify a license for the packaging
[14:54] <Riddell> I still need a ping :)
[14:54] <Laney> :)
[14:54] <rodrigo_> Riddell: sent you a mail also :-)
[14:54] <seb128> Laney, do we care?
[14:54] <Laney> I care, ftpmasters care
[14:54] <Laney> AAs may not
[14:54] <seb128> rodrigo_, seems Laney might want to play sponsor for you ;-)
[14:54] <Riddell> oh e-mail, I'm rubbish with e-mail currently
[14:54] <rodrigo_> Riddell: :)
[14:55] <rodrigo_> Laney: so, what do I need to do?
[14:55] <seb128> Laney, I don't get the point but ok
[14:55] <rodrigo_> Laney: and can it wait for the next submission?
[14:55] <Laney> depends if it will get accepted without it
[14:55] <rodrigo_> Laney: I will submit a new release soon, with lots of fixes, so I can do it later
[14:55] <rodrigo_> Laney: ah
[14:55] <Laney> imo it's important to have a clear license situation for all files
[14:55] <Laney> including debian/
[14:56] <rodrigo_> Riddell: see last comment in http://revu.ubuntuwire.com/p/evolution-couchdb
[14:56] <Laney> you can just put "The Debian packaging is (c) blah blah 2009 and is released under XYZ license, see above
[14:56] <Laney> "
[14:57] <seb128> see any other package for example
[14:57] <Riddell> rodrigo_: shall I add the line Laney suggests and upload then?
[14:57] <seb128> rodrigo_, btw do you think you could roll a g-c-c tarball at some stage?
[14:57] <rodrigo_> Riddell: yes, please
[14:57] <seb128> rodrigo_, no hurry but there was non for 2.27.90
[14:57] <rodrigo_> seb128: I asked vuntz yesterday to do it, not sure if he did, seems not
[14:58] <rodrigo_> seb128: I will later if he hasn't done it
[14:58] <seb128> ok thanks
[15:00] <rodrigo_> Riddell: once you upload it, how long does it take to be able to apt-get source it?
[15:00] <Riddell> rodrigo_: it needs an archive admin to accept it, then it'll take an hour or two to compile, then it needs an archive admin to accept the binaries, then it'll appear within an hour or so
[15:01] <rodrigo_> ok
[15:01] <Laney> from a few hours to a few days ;)
[15:02] <seb128> apt-get source is quicker
[15:02] <seb128> it's just source newing
[15:02] <dobey> seb128: hey. can you get ubuntuone-client 0.92.0 uploaded? was hoping to get it in alpha4...
[15:02] <seb128> dobey, no, alpha4 images were rolled yesterday and it's still frozen
[15:02] <dobey> doh :-/
[15:09] <Riddell> rodrigo_: uploaded, seb128  should be able to review
[15:09] <rodrigo_> Riddell: ok, thanks!
[15:09] <seb128> looking
[15:11] <seb128> Riddell, could you binary new gnome-shell for me?
[15:11] <seb128> I did upload so I try to not new it ;-)
[15:12] <slomo> seb128: do you get the internal flow error only with the bbc plugin or also with mp3s?
[15:12] <seb128> slomo, I tried with a mp3 file on disk
[15:13] <seb128> slomo, but I didn't sync the new -good from yesterday
[15:13] <seb128> since we are frozen for alpha
[15:13] <seb128> in case that makes a difference
[15:13] <slomo> shouldn't make a difference
[15:13] <seb128> want extra details?
[15:13] <slomo> well, test my patch ;) it makes codec installation work again for me
[15:13] <seb128> slomo, ok thanks
[15:14] <slomo> but i don't get the internal dataflow error but something else
[15:14] <seb128> slomo, weird that is was working with old totem
[15:14] <Riddell> seb128: let me look
[15:14] <seb128> if that's a gst bug
[15:15] <slomo> seb128: between 2.26.2 and 2.27.1 totem switched to playbin2
[15:15] <seb128> ah right
[15:15] <slomo> seb128: and playbin2 handled missing plugins incorrectly while playbin did it right
[15:16] <seb128> Riddell, thanks
[15:17] <chrisccoulson> iseb128 - yeah, that  bug report could be similar (sorry, I had to disappear again earlier)
[15:17] <chrisccoulson> i'll try and do some debugging on it later
[15:19] <chrisccoulson> seb128 - xklavier calls XSetErrorHandler(xkl_process_error)
[15:19] <chrisccoulson> there we go ;)
[15:19] <seb128> chrisccoulson, right, it sets an error handler, what I said
[15:19] <Riddell> seb128: E: gnome-shell: python-script-but-no-python-dep ./usr/bin/gnome-shell
[15:19] <Riddell> that seems important
[15:20] <chrisccoulson> seb128 - yeah. so, should i report the bug upstream against xklavier?
[15:20] <seb128> Riddell, thanks for noticing, I expect everybody to have python but will fix in next upload
[15:20] <seb128> chrisccoulson, well how is that a bug?
[15:20] <seb128> chrisccoulson, what I don't get is why trapping doesn't work
[15:21] <seb128> chrisccoulson, lot of software do set crash handlers, ie gnome-session
[15:21] <chrisccoulson> i don't know if that is expected behaviour after registering the handler
[15:21] <seb128> chrisccoulson, btw did you look at changing gnome-session to let apport work?
[15:21] <chrisccoulson> seb128 - the gnome-session change is already in
[15:22] <seb128> DOH
[15:22] <Riddell> seb128: accepted.  bug 413096
[15:22] <seb128> Riddell, thanks!
[15:22] <seb128> chrisccoulson, sorry, you do such good work that I reviewed your changes only quickly
[15:22] <seb128> ;-)
[15:22] <chrisccoulson> heh, no worries ;)
[15:37] <Riddell> rodrigo_: fail  https://launchpad.net/ubuntu/+source/evolution-couchdb/0.1.4-0ubuntu2/+build/1161454/+files/buildlog_ubuntu-karmic-i386.evolution-couchdb_0.1.4-0ubuntu2_FAILEDTOBUILD.txt.gz
[15:37] <chrisccoulson> seb128 - is gdk_x_error called on a trapped error after the application called gdk_error_trap_push ?
[15:38] <chrisccoulson> the only reason i ask is because the debug output from g-s-d in that bug report suggests that the xrandr error was actually trapped correctly
[15:38] <rodrigo_> Riddell: it needs the new couchdb-glib, which is already submitted
[15:38] <rodrigo_> Riddell: I guess it's not fully uploaded yet?
[15:38] <seb128> chrisccoulson, not sure but yes that's what is confusing me
[15:38] <chrisccoulson> i'm just wondering if the backtrace there breaks on the wrong gdk_x_error
[15:38] <seb128> rodrigo_, you need a versioned build-depends in this case
[15:38] <chrisccoulson> maybe it breaks there on the error that was actually trapped correctly?
[15:39] <chrisccoulson> i should probably ask the reporter to continue in GDB after the first error and see if it traps a second one
[15:39] <rodrigo_> seb128: right
[15:39] <seb128> slomo, no, doesn't fix the data flow error
[15:39] <seb128> chrisccoulson, right
[15:41] <slomo> seb128: that's sad... then i can't reproduce your problem, sorry :/ could you reopen the bug with a GST_DEBUG=5 debug log?
[15:44] <rodrigo_> Riddell: https://bugs.launchpad.net/ubuntu/+source/couchdb-glib/+bug/409378
[15:44] <rodrigo_> Riddell: can you please make it build-depend on 0.4.3 and upload again?
[15:45] <Riddell> ok
[15:45] <rodrigo_> Riddell: thanks
[15:46] <Riddell> done
[15:48] <rodrigo_> btw, has anyone looked at the opensuse build service? it makes package submission much easier than what we use in Ubuntu
[15:49] <seb128> how so?
[15:49] <rodrigo_> well, all packages are in repositories, just like vcs'
[15:49] <rodrigo_> and when you want to submit a change, you just branch, then submit
[15:50] <rodrigo_> and changes are available for anyone at any time, no need to wait
[15:51] <rodrigo_> I'm not talking about rpm and deb, deb seems better to me, just the way it works for package submission
[15:52] <seb128> slomo, http://people.canonical.com/~seb128/log.gz useful?
[15:53] <asac> james_w: something like bug 399938 is still happening for us
[15:53] <seb128> rodrigo_, well if you have your packaging in bzr that should be similar
[15:53] <james_w> asac: could you answer my question in the bug?
[15:54] <seb128> rodrigo_, that's what we do for desktop updates for example
[15:54] <CarlFK> where (list prolly) I can post questions about customizing the live CD? (like adding shortcuts on desktop/task bar, autorun, what can I remove to make room...)
[15:54] <rodrigo_> seb128: I guess so, haven't touched any package so far with the sources in bzr
[15:54] <slomo> seb128: probably, i'll try to get it fixed :)
[15:54] <seb128> CarlFK, ubuntu-devel-discuss
[15:54] <seb128> slomo, should I add that to the bug?
[15:54] <seb128> slomo, do you see anything wrong in the log?
[15:54] <rodrigo_> seb128: but the packages in bzr, do they have the tar.gz, or the whole source untarred?
[15:55] <seb128> rodrigo_, you can have whole source or debian dir only
[15:55] <CarlFK> seb128: thanks
[15:55] <rodrigo_> seb128: ah
[15:55] <seb128> rodrigo_, if you have the debian dir only it download from the web for you
[15:55] <seb128> it you tell it where to find the tarballs
[15:55] <rodrigo_> ah, cool
[15:55] <slomo> seb128: please add it to the bug and reopen it... i'm still looking at the log. the only thing that is missing for you is the mp3 decoder, right?
[15:55] <seb128> and it find one matching the changelog version
[15:55] <seb128> slomo, well I only tried with mp3
[15:55] <seb128> slomo, it's a karmic alpha cd
[15:55] <rodrigo_> sounds cooler than the dput / bug with debdiff thing
[15:55] <seb128> slomo, ie only -good installed
[15:56] <seb128> rodrigo_, so review for us is basically bzr checkout, review, push, upload
[15:56] <seb128> or comment, wait for changes, pull, redo, etc
[15:56] <rodrigo_> seb128: ok, understood, seems that should be better indeed
[15:57] <rodrigo_> seb128: and are all packages being moved to bzr?
[15:57] <seb128> yes, import is ongoing
[15:57] <rodrigo_> cool
[15:57] <slomo> seb128: haha, i found the reason :)
[15:57] <slomo> seb128: it's a bug in bluez, their a2dpsink should not have a rank>=marginal
[15:57] <seb128> slomo, oh
[15:57] <slomo> seb128: because it requires manual configuration and can't be autoplugged
[15:58] <seb128> slomo, should I still reopen the bug?
[15:58] <slomo> seb128: so better file a new bug on bluez and link to the totem/gstreamer bug
[15:58] <seb128> slomo, I did dpkg -r bluez-gstreamer
[15:59] <seb128> and still get the issue
[15:59] <slomo> seb128: gst-inspect a2dpsink returns something ?
[16:00] <seb128> slomo, not now
[16:00] <slomo> seb128: ok, then please give me a new debug log without a2dpsink installed and try to find the next problem ;)
[16:02] <seb128> slomo, same location
[16:03] <MacSlow> seb128, do you know what all moved (or is meant to be moved) to devkit-power (apart from keyboard-brightness handling)?
[16:04] <seb128> MacSlow, what all?
[16:04] <seb128> what else you mean?
[16:04] <MacSlow> seb128, I'm nearly done with the screen-brightness patch
[16:04] <seb128> MacSlow, gnome-session
[16:04] <seb128> nothing that should impact your bubbles
[16:04] <MacSlow> seb128, oh.. ehm... hehe... gnome-power-manager I mean
[16:05] <seb128> MacSlow, I don't understand the question
[16:05] <MacSlow> seb128, ok...
[16:05] <slomo> seb128: this is with my patch, right?
[16:05] <seb128> slomo, yes
[16:05] <seb128> slomo, your patch and no bluez-gstreamer
[16:06] <MacSlow> seb128, the patch for gnome-power-manager to make it integrate with notify-osd (for changing screen- and keyboard-brightness) does not apply /work at all with gnome-power-manager 2.27.5
[16:06] <slomo> seb128: ok, interesting :)
[16:06] <MacSlow> seb128, I've fixed most of that
[16:07] <seb128> MacSlow, cool!
[16:07] <MacSlow> seb128, while doing that I was informed (and saw) that the handling of the keys for keyboard-brightness has been moved out of gnome-power-manager ... and apparently been put into devicekit-power (or whatever the packages is called)
[16:08] <seb128> right
[16:08] <slomo> seb128: if it makes you happy, i can reproduce it when remove gst-ffmpeg and gst-plugins-ugly :)
[16:08] <MacSlow> seb128, so my question is... do you know of anything else (battery-level handling) being moved around... or still planned to be moved around by upstreams?
[16:08] <seb128> slomo, good ;-)
[16:09] <seb128> MacSlow, oh ok, I understand the question now, not sure now but I would expect not this cycle
[16:09] <slomo> seb128: please reopen and say that my patch only fixes half of this bug (it doesn't fix the case where things could already be plugged together, it only fixes the case where the first element after the source is missing)
[16:09] <MacSlow> seb128, phew thank god :)
[16:09] <seb128> slomo, done
[16:19] <awe> seb128: if have a deep dbus questions, who's the goto person?  trying to figure out why i can't sniff dbus method calls with dbus-monitor...
[16:20] <seb128> awe, Keybuk probably
[16:21] <seb128> awe, do you know about d-feet?
[16:21] <seb128> useful tool
[16:21] <awe> ok.  that was my first guess.  no, i don't.
[16:21] <Keybuk> awe: what method calls are you trying to see?
[16:22] <Keybuk> the most common mistake is probing the wrong bus
[16:22] <awe> nm-applet ActivateConnection calls to network-manager
[16:22] <asac> he wants to see the method calls from nm (user) to nm daemon (system)
[16:22] <Keybuk> dbus-monitor --system then
[16:23] <awe> yea, that's what i was using, but could only see PropertyChange signals
[16:24] <Keybuk> what signal are you looking for?
[16:24] <asac> not signal ... but method call
[16:24] <Keybuk> oh
[16:24] <Keybuk> you can't do that
[16:24] <awe> I'm not, I wanted to see a method call ( ActivateConnection )
[16:24] <Keybuk> sorry, I confused myself between method calls and messages there
[16:24] <awe> the man page says you can, and it looks like there's code in dbus-monitor
[16:24] <Keybuk> method calls have a destination, so are private between them
[16:24] <Keybuk> awe: the man page does not contain the word "method"
[16:24] <asac> maybe if running as root it works?
[16:25] <Keybuk> I don't think so
[16:25] <asac> seems not to work
[16:25] <asac> yeah
[16:25] <Keybuk> the bus daemon just doesn't work that way
[16:26] <awe> Keybuk, correct, it doesn't have 'method', but it does have watch expressions which support 'type=method_call'
[16:26] <Keybuk> yes, but watch expressions only apply if there's no explicit destination in mind
[16:26] <awe> do private messages get routed thru the daemon?  or are they point-to-point?
[16:27] <Keybuk> method calls always have explicit destinations
[16:27] <Keybuk> they're routed through the daemon
[16:27] <asac> you mean "not routed" ?
[16:28] <Keybuk> basically the security settings get in your way
[16:28] <awe> so basically the limitation ( sounds like a policy limitation ) is that dbus-monitor can only sniff broadcast messages ( eg. signals )
[16:28] <Keybuk> awe: on the system bus, that's correct
[16:29] <awe> but not on the session bus?
[16:29] <awe> so it's a security limitation then...
[16:29] <awe> right?
[16:29] <Keybuk> there's no security policy on the system bus that lets your dbus-monitor client receive the method call messages or their replies
[16:29] <Keybuk> whereas on the session bus there's no security policy at all ;)
[16:29] <awe> Keybuk, ok, then for debugging purposes, it should be possible to craft a debug policy to allow such snoops?
[16:30] <awe> ...on the system bus?

[16:32] <Keybuk>   <policy user="root">
[16:32] <Keybuk>     <allow send_type="method_return"/>
[16:32] <Keybuk>     <allow send_type="method_call"/>
[16:32] <Keybuk>     <allow send_type="error"/>
[16:32] <Keybuk>     <allow send_type="signal"/>
[16:32] <Keybuk>   </policy>

[16:33] <Keybuk> something like that maybe ?
[16:33] <Keybuk> you'll probably have to fiddle around
[16:34] <awe> cool!  Thanks much for the help!
[16:34] <james_w> fta: I don't understand "I see this with bzr-builddeb, with bzr-builddeb and even with python"
[16:35] <fta> james_w, or, or
[16:35] <fta> james_w, i mean, with each of those
[16:35] <james_w> why bzr-builddeb is repeated twice?
[16:35] <fta> oops
[16:35] <fta> dpkg-source is the 2nd
[16:36] <james_w> your paste in the bug doesn't involve bzr-builddeb
[16:37] <james_w> if you provide a trace showing the issue with bzr-builddeb then I can fix any remaining instances of the bug there, but I can't magically make this issue disappear in all cases for you
[16:38] <fta> james_w, i thought the bug was going to tar, not to bzr-builddeb
[16:38] <fta> it's the common factor to all symptoms
[16:46] <Laney> when in the cycle is apport usually disabled? rc?
[16:49] <slomo> seb128: now it's completely fixed, patch is attached
[16:50] <slomo> seb128: if necessary remind me to upload a new -base before the next ubuntu release so you can sync
[16:50] <seb128> Laney, yes
[16:50] <seb128> slomo, ok thanks
[16:50] <seb128> slomo, you don't plan to do that soon?
[16:50] <seb128> slomo, in within a month would be nice
[16:51] <slomo> seb128: it's not that important for debian yet... but i'll do it after 0.10.24-1 moved to testing
[16:51] <seb128> slomo, ok thanks
[16:57] <seb128> slomo, ok that works now, thanks!
[16:58] <seb128> asac, awe: is any of you looking at bluez in ubuntu?
[16:58] <mac_v> pedro_: for Bug #409828 , i believe change needs to be done in notify-osd , since the notification uses it own custom icon set , all the icon changes are done in notify-osd
[16:58] <asac> seb128: file bugs
[16:58] <asac> i will check them later
[16:58] <seb128> asac, ok
[16:58] <asac> next week i want to take a more serious stab at bluez stuff
[16:59] <asac> have to get used to how to debug etc first.
[16:59] <seb128> slomo, how would you describe the bluez issue?
[16:59] <seb128> asac, in this case that's a bluez-gstreamer issue
[16:59] <pedro_> MacSlow, what do you think about that bug? bug 409828
[17:00] <asac> seb128: yeah i can check that too and see if i find someone more appropriate if i have no idea
[17:00] <asac> seb128: is the bluez-gstream buglist still comprehensive ?
[17:00] <asac> havent looked at it yet ;)
[17:01] <MacSlow> pedro_, certainly an application issue and not notify-osd related at all
[17:01] <superm1> seb128, the sink was intentionally registered as marginal: http://git.kernel.org/?p=bluetooth/bluez.git;a=commit;h=013f56322de6ff5a974fed56c8aec56d3b69ef09
[17:01] <mac_v> pedro_: oh... ok
[17:01] <superm1> godog submitted that patch about a month ago
[17:02] <pedro_> MacSlow, thanks
[17:02] <MacSlow> pedro_, the typical symbolic icon-name to use would be "notification-message-im"
[17:03] <seb128> superm1, well slomo says that's buggy
[17:03] <seb128> superm1, and I can confirm it breaks easy codec install
[17:03] <pedro_> MacSlow, yeah that was what i thought
[17:04] <MacSlow> pedro_, just commented with a suggestion to it
[17:04] <superm1> slomo, can you raise that discussion on the linux-bluetooth ML then upstream if it's buggy?
[17:04] <mac_v> pedro_: i got it confused with how notify-osd handles wifi
[17:04] <MacSlow> pedro_, I need to take a break... I'll be available later this evening again
[17:05] <pedro_> MacSlow, great, thanks
[17:05] <pedro_> MacSlow, enjoy , see you later :-)
[17:05] <superm1> seb128, how does the type of sink that is registered break codec install?
[17:06] <seb128> superm1, scroll log for what slomo said before?
[17:06] <superm1> just looked up.  not sure i agree with that though
[17:06] <seb128> superm1, "because it requires manual configuration and can't be autoplugged"
[17:07] <seb128> superm1, well not sure "how" it breaks it but it breaks it
[17:07] <seb128> superm1, totem returns a data flow error when bluez-gstreamer is installed
[17:09] <superm1> seb128, hmm. well still best to see how upstream feels.  godog implemented this in debian a long time ago, so should have affected debian sooner
[17:09] <seb128> superm1, it probably does but bluez-gstreamer might not be installed by default there
[17:10] <superm1> seb128, it's a recommends for the bluetooth meta that we both share (we're on the same basic packaging)
[17:10] <seb128> ok dunno then
[17:10] <superm1> yeah, could just be a new bug with how the codec installer is handling things too
[17:10] <seb128> it's a playbin2 issue
[17:10] <seb128> which is used only since 2.27 in totem
[17:14] <seb128> vuntz, any opinion about changing the value for the number of places items before showing a submenu to 8 by default?
[17:31] <vuntz> seb128: 8 seems like a lot. The menu could be very long
[17:34] <seb128> vuntz, https://bugs.edge.launchpad.net/ubuntu/+source/xdg-user-dirs/+bug/204567/comments/35
[17:35] <seb128> vuntz, but right
[17:39] <seb128> vuntz, there is a patch to add a gconf key to it, might be better ;-)
[17:40] <djsiegel> vuntz seb128, I heard someone say they were allowing 22 items?!
[17:40] <djsiegel> or that was just the max
[17:40] <djsiegel> anyway, gtg for a bit
[17:40] <seb128> djsiegel, that was an estimation of how much can fit on screen
[18:01] <chrisccoulson> seb128 - i just had a look at the GDK code, and gdk_x_error is still the error handler after calling gdk_error_trap_push
[18:01] <chrisccoulson> so that trace in the g-s-d report is of the wrong error ;)
[18:01] <seb128> oh
[18:01] <chrisccoulson> that one is not the one which causes g-s-d to exit
[18:01] <seb128> so it's probably a keyboard error
[18:01] <seb128> ie the warning about xinput not being supported
[18:01] <chrisccoulson> seb128 - yes, probably. at least it all makes perfect sense now:)
[18:02] <chrisccoulson> i suppose we'll just have to wait for a more meaningful backtrace now
[18:02] <seb128> right
[18:13] <chrisccoulson> no alpha 4 yet?
[18:30] <slomo> superm1: do you agree that a2dpsink requires manual configuration and doesn't work without setting the device property? or is there a misunderstanding on my side?
[18:30] <superm1> slomo, i was under the impression the sink just did nothing when it was unconfigured
[18:31] <superm1> but i may be mistaken, so that's why i was recommending bringing it up with upstream to confirm
[18:35] <slomo> superm1: well, the question is if it is useful to be automatically used... if it does nothing then it definitely isn't ;) could you file a bug for this or something? i'm busy with other stuff atm
[18:35] <superm1> unfortunately upstream doesn't have a bug tracker
[20:23] <chrisccoulson> gaaargh, just had another g-s-d crash on login :-/
[20:23]  * chrisccoulson adds --sync to desktop file
[20:29] <MDC1> now that no buttons should have icons - a lot of them still has some icon left (update-manager, alacarte, firefoxs restore dialog, ekiga, etc). What it looks like is that "hand made" buttons where you've added a hbox and then image + label is the one that has this problem compared to using the gtk_button_set_image (). (Seems glade adds a GtkAlignment [GtkHBox [ GtkImage, GtkLabel ] ]). What can be done about this? L
[20:32] <chrisccoulson> seb128 - i've nearly done the brasero update now (just need to test it)
[20:33] <chrisccoulson> i notice it ships some documentation now for the library. do you think i should build this in to a -doc package?
[20:33] <dobey> MDC1: upstream should stop trying to fix UI problems with silly theme hacks, really
[20:34] <MDC1> dobey, theme hacks?
[20:35] <dobey> MDC1: yes. changing the theme to specify no images in buttons. it's a GtkSetting
[20:35] <dobey> MDC1: changing the theme isn't going to fix the UI
[20:36] <MDC1> dobey, well, the change is made and now i'll think we have to do the best about the situation and make ubuntu good looking without icons..
[20:36] <MDC1> *everywhere*
[20:37] <MDC1> dobey, or just make ubuntu use icons by default (changing the gconf setting). But it seems like that aint gonna happen...
[20:38] <dobey> well, like i said. adding a preference isn't a fix...
[20:39] <MDC1> dobey, no, so we should patch all the applications out there or just make gtk "smart"...?
[20:39] <dobey> patch them to do what?
[20:39] <MDC1> remove the icons from the buttons
[20:40] <dobey> no
[20:40] <MDC1> .. when the setting is right..
[20:40] <dobey> i'm sure there are lots of cases where icons in buttons makes sense
[20:40] <dobey> so just blindly removing all icons from buttons is not a fix
[20:40] <seb128> chrisccoulson, no need to bother no
[20:40] <MDC1> of course, so patching each application out there is the solution?
[20:40] <dobey> like i said, having a setting is the wrong fix, no matter how you deal with the setting
[20:40] <chrisccoulson> seb128 - cool:)
[20:40] <seb128> chrisccoulson, the documentation is going to go in language pack soon when pitti is back from vac
[20:40] <chrisccoulson> ok, no problem
[20:41] <seb128> chrisccoulson, the code is ready, it's collection things but not cleaning for now
[20:41] <chrisccoulson> btw, this g-s-d crash i'm seeing seems to be triggered with the introduction of xsplash
[20:41] <chrisccoulson> it seems to go away without. i got a backtrace with the --sync option now
[20:42] <seb128> weird
[20:42] <dobey> MDC1: the proper solution is to do proper evaluation of each application on the basis of usability, and then fix the applications based on that data
[20:42] <seb128> open a bug and get bratsche to look at it
[20:42] <seb128> brb
[20:43] <bratsche> wtf, how would xsplash cause gsd to crash?
[20:43] <chrisccoulson> bratsche - not sure
[20:44] <chrisccoulson> XGetWindowProperty is throwing an unhandled error in xklavier somewhere now, which causes g-s-d to crash
[20:44] <chrisccoulson> its obviously a bug in g-s-d or xklavier, but its just exposed now somehow ;)
[20:44] <MDC1> dobey, maybe we should start with glade and also add a setting to gtk to force always show the icon in the button?
[20:45] <dobey> MDC1: i don't know why, but you're obviously not understanding me :(
[20:45] <chrisccoulson> bratsche - several people are reporting g-s-d crashes caused by unhandled X errors now, but the stacktraces are not useful without the --sync option
[20:45] <chrisccoulson> so its been difficult working out whats going on
[20:45] <chrisccoulson> bratsche - bug 413245 is mine - with the --sync option
[20:46] <MDC1> dobey, yes i understand. But i think before we patch all the applications out there, there should be tools to make it possible
[20:46] <MDC1> dobey, at the moment glade seems to create buttons with hboxes inside instead of using _set_image ()
[20:47] <dobey> _set_image() is broken api anyway
[20:47] <dobey> it really should have the same api as other things where you can set custom icons
[20:48] <dobey> by passing a pixbuf, or stock id, or icon name, or such
[20:48] <dobey> _set_from_icon_name() _set_from_gicon() etc...
[20:48] <MDC1> dobey, so maybe thats the first step we should do?
[20:48] <dobey> and glade/gtkbuilder should use the icon name/stock id methods probably
[20:48] <MDC1> yes
[20:48] <dobey> but that still doesn't fix the problem
[20:49] <dobey> which is that there is a setting for having icons in buttons
[20:49] <dobey> like i said several times already, having a setting for it isn't a solution
[20:49] <MDC1> so we should remove the setting completly?
[20:49] <dobey> ideally, yes
[20:49] <MDC1> will that ever happen?
[20:49] <dobey> i don't know
[20:50] <dobey> it's a completely oxymoronic setting
[20:52] <MDC1> dobey, ok, so - back to square one, what can i do to help this mess? lets say I'd like to fix alacarte - what should I do?
[20:52] <dobey> as i'm sure it doesn't disable icons in other button widgets that aren't specifically GtkButton
[20:54] <MDC1> dobey, no it dont. the priv->image and priv->label inside GtkButton has to be set and only then it will hide the icon IF the global setting has been made
[20:55] <dobey> yes. so like i said. it's broken, and not a fix. it's a hack. instead of fixing the ones that are the problematic usages, it breaks everything.
[20:58] <MDC1> dobey, are the gtk developers working on a proper solution?
[20:59] <dobey> i doubt it
[20:59] <dobey> because the problem isn't with gtk+
[20:59] <dobey> the problem is with different apps
[21:00] <MDC1> so if it's already is a hack - what harm would a little bit more of hack do? ;-)
[21:01] <dobey> more hack !+ better
[21:01] <dobey> it's worse
[21:02] <MDC1> yeah, i know... but if the situation is like it is - what can we do?
[21:02] <dobey> "i have pig flu, it'll be ok if i give it to 50 other people too" <- see, not good :)
[21:02] <seb128> re
[21:02] <seb128> ok, I uploaded my pending changes after freeze
[21:02] <MDC1> hahahaa
[21:02] <seb128> sponsoring now
[21:02] <dobey> well, you could work towards fixing the situation properly
[21:03] <dobey> which is to say, start getting proper usability reviews of applications done, to evaluate where the problematic icons in buttons are
[21:03] <mclasen> the good thing is that there are no problematic icons anymore...
[21:04] <MDC1> mclasen, thing is that it still is - se alacarte for example
[21:04] <dobey> no, there's a problematic lack of icons instead
[21:04] <MDC1> dobey, i get the feeling you didn't like the descision to remove the icons....
[21:06] <bratsche> Hi mclasen, how's it going?
[21:06] <mclasen> good, about to go home, though
[21:06] <dobey> MDC1: i generally dislike the need for pointless extra work
[21:07] <MDC1> dobey, i sure hope they did have good point for all of this...
[21:07] <dobey> not especially, no
[21:07] <chrisccoulson> seb128 - i think i've sort-of figured out my issue with g-s-d crashing here
[21:08] <MDC1> not even to remove the clutter argument?
[21:08] <seb128> chrisccoulson, oh?
[21:08] <chrisccoulson> xklavier sets an error handler to ignore BadWindow errors, because it expects them occasionally
[21:08] <chrisccoulson> but when an application calls gdk_error_trap_{push,pop}, the error handler is reset to gdk_x_error
[21:08] <dobey> MDC1: what remove the clutter argument?
[21:08] <chrisccoulson> so when xklavier triggers a BadWindow error later, it is not caught
[21:09] <chrisccoulson> that seems to be whats happening in my case anyway
[21:09] <seb128> chrisccoulson, ohhhhh
[21:09] <chrisccoulson> not sure how best to fix that one though :-/
[21:09] <MDC1> dobey, the reason why they did remove the icons (as i understand) was to remove the clutter and make the ui "cleaner"...
[21:09] <bratsche> Is there an easy way to run/test gdm changes without installing gdm? :)
[21:10] <chrisccoulson> seb128 - that could be responsible for a lot of g-s-d crashers
[21:10] <dobey> MDC1: well i suppose that might be a valid argument were it actually true
[21:10] <chrisccoulson> seb128 - bug 413245
[21:10] <bratsche> chrisccoulson: Is it related to xsplash somehow, or is it something else?
[21:10] <dobey> MDC1: but since the desktop now looks half broken, it's worse
[21:10] <chrisccoulson> bratsche - i think its just "exposed" by xsplash
[21:10] <seb128> chrisccoulson, yes, what I said before
[21:10] <bratsche> chrisccoulson: I just did an update and can't reproduce yet.
[21:11] <chrisccoulson> bratsche - it could just be coincidental on my setup
[21:11] <MDC1> dobey, well that's my point and i'm trying to do something about it - just not sure how :)
[21:11] <bratsche> chrisccoulson: I'm hacking on gdm a bit.. do you know how to easily test it without installing it?
[21:12] <chrisccoulson> bratsche - i'm not too sure about that actually, other than testing it in a VM
[21:12] <seb128> chrisccoulson, would make sense with all those bugs where things were confusing with xklavier
[21:12] <seb128> bratsche, what do you want to test?
[21:12] <chrisccoulson> seb128 - yeah, possibly. i'll see if i can figure out a way to work around it here, just to prove it. i don't want to get too excited just yet;)
[21:13] <seb128> dobey, we are unfrozen I uploaded your update
[21:13] <seb128> chrisccoulson, easy way "comment the libklavier code you suspect"
[21:13] <dobey> MDC1: i would probably change alacarte to not be a dialog, and not use buttons.
[21:13] <dobey> seb128: great, thanks!
[21:14] <chrisccoulson> seb128 - possibly. i might try that in a bit:)
[21:14] <bratsche> seb128: I'm making changes to the panel in gdm and want to test it.
[21:17] <bratsche> I can setup a VM though if I need to.
[21:18] <dobey> MDC1: the menu editor ui is a bit complicated for being a dialog, i think
[21:19] <MDC1> dobey, well, alacarte has just a (good) example because its a small application with lots of icons on the buttons
[21:20] <dobey> well it has a vertical array with a lot of buttons
[21:20] <dobey> which is generally bad
[21:20] <dobey> *shrug*
[21:21] <dobey> most applications where icons in buttons are a problem, are just not very well designed applications in the first place, and removing the icons from buttons doesn't change that
[21:21] <MDC1> dobey, i'm not looking into rewriting a complete app, just fixing what can be done to make it not look like shit...
[21:22] <dobey> MDC1: gconftool-2 -t bool -s /desktop/gnome/interface/buttons_have_icons true
[21:22] <MDC1> dobey, well, i know how to fix that, i'm thinking about the "users" of ubuntu
[21:24] <dobey> yes, and the best thing to do is default that setting to true in ubuntu
[21:25] <dobey> every app probably isn't going to be neutered to behave properly with that by freeze
[21:27] <seb128> bratsche, there is test binaries in the source
[21:27] <seb128> bratsche, you might want to try those
[21:29] <chrisccoulson> seb128 - i think i'm wrong :-/ xklavier actually saves the original error handler, and invokes it if the error is not one which it is expecting
[21:29] <chrisccoulson> so from my backtrace, you see _XError -> xkl_process_error -> gdk_x_error
[21:30] <seb128> bah
[21:30] <seb128> why does my keybinding keep breaking!
[21:31] <MDC1> dobey, probably not, but if we start by now then maybe we could be ready in +1 or +2...
[21:33] <seb128> re
[21:33] <seb128> does anybody else has anything to get sponsored?
[21:33] <dobey> MDC1: all the more reason to enable icons by default, and start looking into proper fixes for the problems
[21:34] <seb128> or want to do an update?
[21:35] <chrisccoulson> seb128 - i can push brasero in a minute
[21:36] <seb128> cool
[21:36] <chrisccoulson> i need to test it first though ;)
[21:37] <dobey> seb128: i want a sentient script that automatically fixes bugs :)
[21:51] <chrisccoulson> seb128 - i've pushed the brasero update now
[21:59] <seb128> chrisccoulson, ok
[22:41] <chrisccoulson> seb128 - my g-s-d backtrace is still meaningless. even with the --sync option, it is actually running asynchronously
[22:42] <chrisccoulson> the media keys plugin turns off sync
[22:42] <seb128> not easy to debuyg g-s-d
[22:42] <chrisccoulson> it's not :-.
[22:43] <chrisccoulson> i just ran it through GDB to break on XSynchronize, and sync is turned off before the keyboard plugin loads, and is never turned back on again
[22:43] <chrisccoulson> that'll explain why XGetWindowProperty apparently returns an error in my trace which should not be possible
[22:44] <chrisccoulson> late night ahead ;)
[22:45] <seb128> how does it turn sync?
[22:45] <chrisccoulson> seb128 - gdk calls XSynchronize with TRUE if we want sync on (ie, run it with "--sync")
[22:45] <chrisccoulson> but some call in libpulse turns it back off again later on
[22:46] <chrisccoulson> and never turns it on again
[22:48] <seb128> rodrigo_, there?
[22:49] <chrisccoulson> seb128 - FYI, http://pastebin.ubuntu.com/252782/ shows my output in GDB, breaking on XSynchronize when starting g-s-d, and getting a backtrace each time
[22:49] <seb128> hum ok
[22:49] <seb128> do you get pulse used if you don't active the media key?
[22:50] <chrisccoulson> seb128 - no, i'm going to disable media-keys for now
[22:50] <seb128> ok
[22:50] <chrisccoulson> but i think i should report a bug against pulseaudio, because that issue will make any X application impossible to debug
[22:51] <seb128> right
[22:52] <seb128> there might be a pulseaudio channel
[22:53] <seb128> otherwise lennart is on the gnome irc
[22:53] <seb128> if you want to ping him about that
[23:02] <chrisccoulson> seb128 - thanks
[23:16] <TheMuso> chrisccoulson: Yes #pulseaudio exists.
[23:16] <chrisccoulson> hey TheMuso - thanks
[23:17] <chrisccoulson> i'm not sure my issue is a PA one now though. it only calls XOpenDisplay, which seems to then call XSynchronize. not sure of any way around that really :-/
[23:19] <chrisccoulson> i will work out whats going on eventually!
[23:25] <TheMuso> ok
[23:31] <bratsche> Does desktop background fading/transition seem quite slow/choppy for anyone but me?
[23:31] <bratsche> Maybe it's just video hardware.  It's fine on my nvidia desktop.  Just really slow and choppy on my Intel laptop.
[23:32] <bratsche> Nevermind.
[23:33] <chrisccoulson> bratsche - it's very slow and choppy for me
[23:34] <bratsche> It's very smooth on my nvidia though, so I guess we're trying to do something fancy here and it's sucking on Intel.
[23:35] <chrisccoulson> i havent tried with my nvidia hardware yet
[23:35] <chrisccoulson> i'm sure it will look much nicer on my nvidia card
[23:36] <bratsche> That's too bad.
[23:36] <bratsche> Are you on Intel right now?  What do you have now?
[23:36] <chrisccoulson> i'm running it in VMWare at the moment - so that probably sucks more than intel ;)
[23:37] <bratsche> Oh yeah, I'm sure. :)
[23:37] <bratsche> Have you run xsplash in vmware btw?  Is it remotely smooth?
[23:37] <chrisccoulson> vmware is where it is really choppy at the moment
[23:37] <bratsche> Oh well.
[23:38] <chrisccoulson> yeah, there's probably not much you can do about that
[23:38] <chrisccoulson> it serves me right for not having hardware acceleration in there ;)
[23:38] <bratsche> :)
[23:39] <chrisccoulson> i will get around to installing it on some real hardware next week
[23:39] <bratsche> My Intel SSD arrived in the mail today.  I shouldn't install it tonight, but I probably will anyway. :)
[23:39] <chrisccoulson> and then i will tell you what it's like on my 8800GTX ;)
[23:39] <bratsche> heh
[23:39] <chrisccoulson> how big is the SSD?
[23:39] <bratsche> 80gig
[23:39] <chrisccoulson> nice:)
[23:40] <bratsche> 8800gtx seems like such overkill for a desktop. :)
[23:40] <chrisccoulson> yeah, it is. my desktop is like one big heater
[23:40] <chrisccoulson> it runs about 100W idle, and that is without the monitor on
[23:40] <bratsche> heh.. those can be nice if you live in a cold place. :)
[23:40] <chrisccoulson> yeah, its quite useful in the winter
[23:42] <bratsche> At my first job the office was really cold in the winter.. we had some distcc-like plugin for Visual Studio called "IncrediBuild", and any time someone in the office was doing a build then my little laptop would fire up and start pumping out warm air.
[23:42] <bratsche> And I'd warm my hands in the sweet exhaust of C++ code being compiled.
[23:42] <chrisccoulson> lol, that's quite funny!
[23:43] <chrisccoulson> i sit right under and air conditioner at work, and i'm always really cold!
[23:43] <bratsche> Now I live in Dallas and I can't get cool enough.
[23:44] <chrisccoulson> we have 2 heater/air conditioner units in our office, and they aren't linked in any way. we quite often find that one of them ends up pumping out hot air to warm the office up while the other one pumps out cold air to cool the office down!
[23:44] <chrisccoulson> thats really energy efficient;)
[23:44] <bratsche> Wow.. that's terrible.
[23:44] <chrisccoulson> i always get the cold air!
[23:45] <bratsche> That's the better air to get, at least.
[23:45] <chrisccoulson> yeah, probably. i get quite uncomfortable in the heat
[23:45] <chrisccoulson> i wouldn't mind working in a building with some windows though ;)
[23:45] <bratsche> Windows are nice.
[23:46] <chrisccoulson> yeah, i worked in a building with windows once. but i only worked for that company for 11 months
[23:46] <bratsche> I've been working from home for too long. :/
[23:47] <chrisccoulson> i could work from home. that would be useful, especially when my daughter arrives!
[23:47] <bratsche> Yeah, I'd like it more then.  But I just live alone and it gets boring pretty quickly. :)
[23:48] <chrisccoulson> yeah, i can imagine that. some of my colleagues have worked from home before, and they got bored for that reason too
[23:48] <chrisccoulson> but i think i could probably get used to it for a bit
[23:49] <chrisccoulson> that should be a pre-requisite of my next job
[23:50] <bratsche> I just need to clean up my little office room and I'll feel better again.  I've got stacks of music and books and boxes still from when I moved back to Dallas. :)
[23:50] <chrisccoulson> yeah, i tend to leave stacks of books and magazines around too. and when i moved to my current house, i left a lot of stuff in boxes for ages
[23:50] <chrisccoulson> but my girlfriend just cleans it all away now
[23:51] <chrisccoulson> and then i can't find stuff ;)
[23:51] <chrisccoulson> i'm quite messy. i have the untidiest desk in our office :D
[23:51] <bratsche> heh
[23:51] <chrisccoulson> my boss keeps hinting to me that i should clean it
[23:51] <bratsche> My desk is fine, it's just too small and I have two 21" screens and a laptop on it.
[23:52] <chrisccoulson> i just said that i'd rather move desk and leave all my junk behind at my old desk ;)
[23:52] <chrisccoulson> two 21" screens - nice:)
[23:53] <bratsche> Well, one of them I'm not using that much now.  At my last job I did a lot of Win32 work, so I have a Win32 machine setup here with a screen on it that I'm not doing much with now.
[23:53] <chrisccoulson> i havent used Win32 at home for a long time now
[23:53] <chrisccoulson> i still have to use it at work though
[23:54] <bratsche> I kind of miss hacking on gtk+ on Win32.  I want to get back into it.
[23:54] <chrisccoulson> how come? you could hack on gtk+ on linux instead ;)
[23:54] <bratsche> I want to do both :)
[23:55] <chrisccoulson> i've never done anything with win32 before
[23:55] <chrisccoulson> saying that, i didn't really know any software at all until this last year