[01:28] <rickspencer3> RAOF, hey, around at all?
[01:28] <RAOF> rickspencer3: Yup.  What's up?
[01:29] <rickspencer3> well, someone asked me to join a call tomorrow morning ...
[01:29] <rickspencer3> and it just occurred to me that they are probably concerned about ...
[01:29] <rickspencer3> how will Ubuntu work in VMs in a Wayland world?
[01:30] <RAOF> And they'd be asking a very good question.
[01:30] <rickspencer3> RAOF, does wayland mean that VM vendors will have to simulate 3d hardware so the kernel thinks it do DRI?
[01:30]  * rickspencer3 exposes obvious gross ignorance 
[01:30] <RAOF> No.  Wayland is not dependent on dri per-se.
[01:31] <rickspencer3> hmmp
[01:31] <RAOF> It *is* dependent on some interprocess buffer communication.  That can be done with shared memory (and, indeed, I think there are working patches using shared memory).
[01:32] <RAOF> The question would really be: does the Unity-Wayland compositor support a running without GL.
[01:33] <RAOF> Because Wayland isn't a display manager in the same way that X is a display manager.
[01:33] <rickspencer3> RAOF, GL being the API?
[01:33] <RAOF> Yeah.
[01:33] <walters> wayland definitely depends on EGL, which in turn is implemented by mesa, which itself talks to kernel GPU apis
[01:33] <walters> http://www.spinics.net/lists/linux-virtualization/msg11819.html is a useful post
[01:33]  * rickspencer3 looks
[01:33] <RAOF> walters: Not if you're using the shared memory patches.
[01:33] <walters> apparently mesa pure software rendering is getting better too
[01:34] <RAOF> walters: There's a shared-memory compositor that doesn't require anything fancy.
[01:34] <rickspencer3> in any case, VM vendors will have to have some implementation of the GL API that works?
[01:34] <RAOF> No.
[01:35] <RAOF> Not if Unity-Wayland has a shared-memory non-GL compositor codepath.
[01:35] <walters> i don't know what you mean by shared memory here
[01:35] <RAOF> rickspencer3: In the X world, the display server, window manager, panel, and compositor can all be separate processes.  In the Wayland world, “Wayland” is a library that the combined compositor/panel/window-manager/compositor process links to to provide a display server.
[01:36] <walters> wayland definitely hard depends on EGL in git as is today
[01:36] <walters> anyways i have to go, nite all
[01:36] <RAOF> walters: Yes, it does.  However, there are patches to remove those, and pass blobs of /dev/shm around as buffers rather than EGL images.
[01:36] <rickspencer3> RAOF, right, but I thought the rub was that Wayland uses the 3d capabilities built into kernels now
[01:37] <rickspencer3> and without 3d hardware, those capabilities would be missing
[01:37] <rickspencer3> (this is why I presumed DRI was involved)
[01:37] <RAOF> rickspencer3: At the moment, in trunk, it does.  There's no hard requirement for that to be the case, though.
[01:38] <rickspencer3> right, so you are saying that it's possible that Wayland could have what amounts to a 2d implementation if 3d capabilities are not available in the kernel
[01:38] <RAOF> Right.
[01:38] <RAOF> Indeed, patches to that effect exist.
[01:38] <rickspencer3> but would it not also be possible for VM vendor to let the VM actually use the existing 3d hardware?
[01:39] <RAOF> But it's a bit misleading to say “Wayland could have a 2d implementation…”.  Because what's *really* important is the compositor, which is something that other people develop.
[01:39] <RAOF> (The current compositor in wayland git is just a demo)
[01:39] <rickspencer3> you mean the wayland compisitor could use an API that is not a 3d API?
[01:39] <RAOF> *A* wayland compositor could indeed use an API that's not a 3D API.
[01:40]  * rickspencer3 drums fingers
[01:40] <RAOF> There will be multiple Wayland compositors; a Unity compositor, a GNOME compositor, a KDE compositor… each of these will implement the Wayland protocol.
[01:40] <RAOF> (Presumably by linking with libwayland)
[01:40] <rickspencer3> right right right
[01:40] <rickspencer3> but does not libwayland use 3d graphics directly?
[01:40] <rickspencer3> I thought that was kind of the point
[01:40] <RAOF> No.
[01:41] <RAOF> It's designed around passing references to some “buffer” thing.
[01:41] <RAOF> The kernel drm provides a nice 32bit integer handle for buffers, so it's a natural fit, but it doesn't *have* to be a drm buffer.
[01:43] <RAOF> libwayland itself doesn't do any drawing; that's the job of the compositor.  So libwayland doesn't necessarily need to know what a buffer is, just how to pass references to them around.
[01:43] <rickspencer3> RAOF, but it's the compositor that is written to talk to DRM, not wayland itself?
[01:44] <rickspencer3> I see, so Wayland is more like an arbiter of graphics buffers that works at the behest of a compisitor?
[01:44] <RAOF> Right.
[01:45] <rickspencer3> so a GUI toolkit, for example, knows how to talk to Wayland, which in turn knows how to ask the active compistor to draw?
[01:45] <RAOF> Right.  If you're using the current demo compositor, what's happening is that a “buffer” is currently an EGL image, which is essentially a small wrapper around a DRM buffer.  It hands these out to clients, and the compositor uses GL (or GLES, I forget if that's been done yet) to composit these EGL buffers.
[01:46] <RAOF> The GUI toolkit knows how to talk to Wayland.  From Wayland it gets a buffer.  The GUI toolkit knows how to draw to these buffers, and then tell Wayland “hey, I've updated this buffer, kindly display it”.
[01:46] <RAOF> One of the principles of Wayland is that clients are in charge of their drawing.  Wayland has no drawing APIs.
[01:46] <rickspencer3> and then Wayland says, "he compositor, update the image"
[01:47] <rickspencer3> and the compisitor maybe or may not use 3d hardware, depending on how it was written?
[01:47] <RAOF> Right.
[01:47] <RAOF> Now, I'm not *entirely* sure how this will work in a world where your compositor may use 3D or not depending on hardware support.
[01:48] <rickspencer3> so for Unity-Wayland, support for non 3d capable hardware is tbd
[01:48] <RAOF> Because that will change what “buffer” means, and that means clients will need to know.
[01:48] <rickspencer3> well, I would assume it would be a totally different compositor
[01:49] <RAOF> Right.  But the *client* needs to know how to draw to a buffer.  And if the different compositor provides *different* buffers…
[01:49] <rickspencer3> the client being a gui toolkit for example?
[01:49] <RAOF> How does the client (a) tell between the different types of buffers, and (b) know how to draw the right way?
[01:49] <RAOF> Yeah.
[01:50] <RAOF> The client will be something using GTK, Qt, Cairo, GL, etc...
[01:50] <rickspencer3> but that would imply a toolkit needs to be ported per compositor implementation
[01:50] <rickspencer3> wouldn
[01:50] <rickspencer3> t the client *be* GTK, Qt, etc...?
[01:50] <RAOF> Indeed it would.  Which is why I'm not sure what's happening here.
[01:51] <rickspencer3> so, there would need to be a limited number of compositors, or at least buffer types that compositors use
[01:51] <rickspencer3> because I don't see toolkits being too useful if their very core rendering code needs to be massively specialized per compositor
[01:51] <RAOF> It's also possible that I've misunderstood some of this, and this problem doesn't in fact arise.
[01:52] <rickspencer3> well, it's ok, I'm a dope and it's out of scope
[01:52] <rickspencer3> :)
[01:52] <rickspencer3> I think my takeaway message will be "we don't know, but this is still all far off, so don't worry too much"
[01:52] <RAOF> I don't think it's entirely accurate to call GTK the client - the applications are the clients, they just use GTK or Qt or whatever to make their lives easier.
[01:52] <RAOF> That's an excellent take away message :)
[01:53] <rickspencer3> surely GTK is the client
[01:53] <rickspencer3> I write an application with GTK, GTK will handle drawing
[01:53] <rickspencer3> but I guess GTK isn't a running process
[01:53] <RAOF> So, I'd say that in my current session I have a bunch of X clients - compiz, smuxi, evolution, firefox.
[01:54] <rickspencer3> right, I see what you're saying
[01:54] <RAOF> You can also use multiple toolkits in a single app - See any clutter app, for example; that's using GTK and GL(ES).
[01:54] <rickspencer3> so each application is using GTK as a library to handle writing to the buffers that Wayland gives it
[01:55] <rickspencer3> but, conceptually, it's GTK, not your app, that knows how to use X, or in the future Wayland
[01:55] <RAOF> Right.  Almost all applications don't actually care about drawing per-se.  They care about having a button marked ‘Awesome’ which causes your mail to combusst.
[01:56] <RAOF> And those which do want to do something more than just drawing pre-formed GTK widgets get a Cairo context from GTK and draw to that using Cairo ☺
[01:56] <rickspencer3> well, that's *after* they use a goocanvas
[01:57] <RAOF> Not necessarily - GTK will give you a cairo context for whatever you like.  That's how Do gets drawn.
[01:58] <RAOF> You can also do funky stuff with otherwise standard GTK widgets that way.
[01:59] <rickspencer3> RAOF, yeah, but goo canvas is sick easy
[01:59]  * RAOF hasn't touched goo canvas at all.
[02:00] <rickspencer3> well, it lets you stuff VML into it, essentially
[02:00] <RAOF> Ah.  Higher level fun!
[02:00] <rickspencer3> that's what I'm saying, if you don't have a standard widget that does what you want, you party with goo canvas
[02:01] <rickspencer3> then when that stops doing what you need, you get a cairo context from *that*
[02:01] <RAOF> Aaaaaaaah.  Yes, makes sense.
[02:01] <rickspencer3> RAOF, thanks for your time
[02:01] <rickspencer3> I appreciate you educating me more about Wayland
[02:02] <RAOF> No problem.  It's interesting stuff.
[02:02] <rickspencer3> I'm still skeptical that toolkits will have to be rewritten per wayland compositor
[02:02] <rickspencer3> but that's probably just a sign of how much more I don't understand about it
[02:03] <rickspencer3> later dude, have a good day
[02:03] <RAOF> You too!
[03:41] <Amaranth> RAOF: All the client really needs to know is what format the compositor expects data in the buffer to be (RGBA, BGRA, etc)
[03:41] <Amaranth> RAOF: Actually I imagine those would be the only two formats
[03:42] <RAOF> Amaranth: But it's not passing the contents of the buffer; it's passing a reference to the buffer.  You're going to need to do different things to render to a drm buffer than you are to some piece of /dev/shm
[03:43] <RAOF> If it were passing the contents of the buffer, certianly.  I don't think that's what it does, though.
[03:43] <Amaranth> RAOF: Does the client actually have to use its own code for that though? I thought there was a wayland API
[03:44]  * RAOF goes and has a look.
[03:44] <Amaranth> If not that's the obvious answer
[03:45] <Amaranth> All the client needs is an API to say "render this buffer" or "render this data"
[03:46] <Amaranth> So if the client uses GL and tells it to render a buffer the compositor can take a shortcut but if the client says render this data the compositor loads it in to a texture first
[03:46] <Amaranth> And etc if the compositor is using software rendering
[03:47] <Amaranth> hmm, actually...
[03:47] <RAOF> So, currently the demo clients use clients/window.c as their utility code, and it #ifdefs between GL and shm surfaces.
[03:48] <Amaranth> Forget all that, but the only thing wayland is going to give a client is an EGL handle or a chunk of /dev/shm so they just need a way to tell the difference
[03:48] <Amaranth> A way to query the server
[03:49] <Amaranth> Although how do you run a GL app when you have an shm-based server?
[03:50] <RAOF> You'd need and EGL extension, I think.
[03:51] <Amaranth> No matter what you're going to be reading data from VRAM every frame
[03:51] <Amaranth> So that's going to suck
[03:51] <Amaranth> I suppose you could just say "you can't do that"
[03:52] <Amaranth> But writing a 2D compiz/unity in wayland world is going to be a pain
[03:53] <RAOF> I guess if you're compositor has fallen back to shm buffers it probably means that GL just won't work, so you don't need to care ☺
[03:53] <Amaranth> Until you get a guy who thinks shm is faster/cleaner/uses less memory or something
[03:57] <RAOF> And, well, they get to use software rendering for everything.
[04:37] <RAOF> Amaranth: If you're interested, wayland *clients* currently have two options when attaching a buffer to a window: they can attach a named drm buffer (having previously created & named it via the magic of libdrm), or they can attach a shm buffer and feed the data over an fd.
[08:27] <seb128> hey
[08:27] <cdbs> Hi seb128 , hows it goin' ?
[08:31] <seb128> hey cdbs, I'm fine thank you
[08:31] <seb128> cdbs, how are you?
[08:31] <cdbs> fine, but busy in boring non-ubuntu work :(
[08:32] <seb128> robert_ancell, hey
[08:37] <joaopinto> seb128, kenvandine , the cause for the appindicator missing custom icon was that there was no indicator applet on the panel
[08:37] <seb128> ...
[08:37] <seb128> so you had the fallback to the notification area?
[08:37] <seb128> joaopinto, sorry for not thinking about that
[08:38] <joaopinto> no, it must be the appindicator code doing it, I have no code for the notification area, somehow it places the icon/menu on the panel
[08:38] <joaopinto> with a proper icon for theme base icons, and missing for custom
[08:39] <seb128> right, as said you use the fallback
[08:39] <seb128> the appindicator library does that
[08:39] <joaopinto> ah, ok :)
[08:39] <seb128> if they is no indicator support it fallbacks to a notification icon
[08:39] <seb128> there is probably a bug in the fallback case
[08:39] <seb128> that's not something we test much since all ubuntu install have indicator support
[08:39] <seb128> but feel free to open a bug on indicator-application
[08:40] <joaopinto> ok I will
[08:40] <seb128> thanks
[08:40] <joaopinto> libappindicator1 ?
[08:41] <joaopinto> a bug against indicator-application ?
[08:42] <seb128> joaopinto, https://edge.launchpad.net/indicator-application/+filebug
[09:14] <joaopinto> seb128, do you have any idea why the following code behaves different when executed from a appindicator menu vs the tray context menu: http://pastebin.ubuntu.com/544346/
[09:14] <joaopinto> when launched from the indicator the dialog does not respond to the close window action
[09:15] <seb128> joaopinto, hum, no
[09:18] <joaopinto> :( let's see if adding a closing signal handler helps
[09:31] <joaopinto> uff, gtk.main_quit() does not quit either
[09:32] <seb128> does it works as standalone code?
[09:35] <joaopinto> yes, I am migrating from tray to appindicator
[09:36] <joaopinto> I am still showing the notification area in parallel, and the function call works as expected
[09:36] <seb128> try asking on #ayatana
[09:36] <joaopinto> The delete_event is received in both cases, but with the indicator the dialog is not destroyed
[09:36] <seb128> it's the upstream channel for what dx does
[09:36] <seb128> they probably know better than the desktop team
[09:57] <mpt> mvo, good morning
[09:58] <mpt> mvo, when I suggested that "Show Residual Settings" command for things you've removed but not purged, is that actually technically possible? Or is there no way to tell what settings are left behind after you've removed a package?
[09:59] <seb128> mpt, it's possible I guess
[10:00] <seb128> since you can dpkg -L those
[10:00] <seb128> so the info is on disk
[10:01] <joaopinto> seb128, not after removing the package...
[10:01] <mpt> dpkg -L takes a package name argument
[10:01] <mpt> What I'm looking for is, "Show the list of packages that I removed in the past but didn't purge"
[10:02] <mpt> "... and that left files behind as a result"
[10:02] <seb128> mpt, dpkg -l | grep ^rc
[10:02] <seb128> then dpkg -L <binary>
[10:02] <seb128> on one of those
[10:02] <seb128> joaopinto, if the package is still configured which is what mpt is asking for it works
[10:04] <joaopinto> right, the info is still available from /var/lib/dpkg/info/package.list
[10:04] <mpt> ah
[10:04] <mpt> I don't have one of those
[10:04] <mvo> mpt: what seb128 said, its possible to get this data, dpkg keeps them in the db
[10:05] <mpt> excellent
[10:05] <mpt> thanks seb128
[10:05] <seb128> you're welcome
[10:09] <huats> morning
[10:10] <mpt> mvo, oh, cool, I love what happens in trunk when I search for "abbieword"
[10:11] <mvo> mpt: yeah, me too, I think its a really cool feature
[10:13] <mpt> mvo, maybe the spelling suggestions should show if there's a close match even when there are matches for what you did type. E.g. if I type "movida" it's very likely that I want Moovida, not deskbar-applet or dwm.
[10:14] <mvo> mpt: yeah, glatzor suggested that yesterday too, I will add it
[10:17] <mpt> In that case, we need to work out consistent presentation for three possibilities: (a) there are matches but no spelling suggestion; (b) there's a spelling suggestion but no matches (so therefore there are other suggestions); (c) there's both a spelling suggestion and matches.
[10:19] <mvo> mpt: indeed, the next thing is there will be suggestions that are not useful. movida->moovida is a good one, but we will probably have "apt" -> "app" and similar cases, especially for short words
[10:19] <mvo> mpt: we could simply lmit the suggestions (if there are hits) for 3 letter words as they will most likley result in overlay broad ones
[10:20] <mvo> mpt: maybe even for 4 letters, that probably requires a bit of tweaking. the algorithm will look for a maximum of matches, but that is not always what we want
[10:21] <mpt> mvo, maybe show a suggestion if (number of results for the suggestion) >= N * (number of results for the current string)
[10:22] <mpt> Hm, that wouldn't fix the apt->app case though probably
[10:22] <mvo> that would be valid for apt -> app too
[10:22] <mpt> I don't see why deskbar-applet or dwm are showing up as results for "movida" in the first place
[10:24] <mpt> Their data doesn't contain that string
[10:32] <mvo> mpt: odd, I just tried that and it does not show them for me
[10:32] <mvo> it suggests moovida
[10:32] <mpt> And it has a "Hide 2 technical items" link that does nothing except flash the window
[10:33] <mvo> search term was "movida"
[10:33] <mvo> ?
[10:36] <mpt> mvo, http://people.canonical.com/~mpt/movida.ogv
[10:38] <mvo> mpt: maverick or natty?
[10:38] <mpt> Maverick
[10:39]  * mvo scratches head
[10:49] <seb128> Riddell, there?
[10:50] <Riddell> hi seb128
[10:50] <seb128> Riddell, hey, do you think you can review and bin NEW gobject-introspection for me?
[10:50] <seb128> the binary need to be promoted directly
[10:50] <Riddell> let me look
[10:52] <seb128> Riddell, thanks
[10:54] <Riddell> accepted!
[10:56] <seb128> Riddell, thanks
[11:36] <ari-tczew> robert_ancell: around?
[11:37] <seb128> ari-tczew, not likely, he stopped his work day for 5 hours or so
[11:37] <ari-tczew> ok
[11:37] <seb128> what do you need? just ask on the channel in case?
[11:37] <ari-tczew> seb128: sponsorship
[11:38] <seb128> subscribe ubuntu-sponsors?
[11:38] <seb128> if that's for ubuntu
[11:38] <seb128> or is that for a ppa upload?
[11:38] <seb128> or ping the patch pilot
[11:38] <ari-tczew> seb128: I'd like to be sponsored specially by robert_ancell
[11:39] <seb128> is there any reason?
[11:39] <seb128> but anyway your call, that will have to wait tomorrow then
[11:39] <seb128> drop him an email or subscribe him to the bug
[11:40] <ari-tczew> seb128: I subscribed yesterday
[11:40] <ari-tczew> seb128: I'm collecting a sponsored uploads to get endorsements in future
[11:41] <ari-tczew> and I choiced robert_ancell. I've talked with him about it, don't worry
[11:41] <seb128> ok
[11:41] <seb128> well you don't need uploads only by a specific sponsor
[11:42] <ari-tczew> seb128: how another way do you want build an endorsement?
[11:42] <seb128> you can just keep track of things that got sponsored and ask different endorsements
[11:42] <seb128> well most people get endorsement of at least 3 sponsors
[11:42] <ari-tczew> seb128: I have 2.
[11:42] <seb128> not sure you win by limiting those
[11:42] <seb128> it just show that you don't want to work with the community but just specific people
[11:42] <ari-tczew> seb128: for MOTU app I collected 9 endorsements :P
[11:43] <seb128> which is a bit weird
[11:43] <ari-tczew> seb128: hmm, it's not like you got it
[11:43] <ari-tczew> if I have a problem, I'm talking with community
[11:45] <seb128> ari-tczew, ok, alright
[11:45] <seb128> I was just pointing that having different sponsors usually doesn't hurt
[11:46] <ari-tczew> seb128: and I have different sponsors ;)
[11:46] <geser> I guess it's more about not spreading the sponsored uploads across to many sponsors, as some sponsors won't have an opinion about endorsments with too few sponsored uploads
[11:46] <ari-tczew> maybe do you want me to do some merges and sponsor it?
[11:47] <ari-tczew> geser: +1. that's what I wanted to tell seb128
[11:48] <seb128> ari-tczew, no that's fine, if robert_ancell is taking care of your uploads that works for me ;-)
[11:48] <seb128> I'm not asking for extra work ;-)
[11:59] <seb128> Riddell, there is another rounds of gir binaries in NEW if you feel like reviewing those as well
[12:10] <Riddell> seb128: ok
[12:42] <seb128> Riddell, thanks
[12:49] <Riddell> seb128: accepted
[12:50] <seb128> Riddell, thank you!
[12:50] <Riddell> bug 691069 should be fixed I think
[12:50] <ubot2> Launchpad bug 691069 in gstreamer0.10 (Ubuntu) "copyright-without-copyright-notice (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/691069
[12:50] <Riddell> seb128: how come these gir files aren't just put into the -dev packages?
[12:50] <seb128> Riddell, they are runtime
[12:52] <seb128> Riddell, the .gir which are used at build are in the libdev binaries
[12:52] <seb128> Riddell, the gir1... content is what is used at runtime from python or js
[12:53] <seb128> so it could go in the library, but debian decided to not do that because the gir abi is breaking at different times from the soname
[12:53] <seb128> it wouldn't work well for transitions
[12:53] <seb128> like now only the gir format changes, the lib abi didn't
[12:54] <Riddell> right, makes sense
[14:12] <chrisccoulson> mterry - i've not uploaded the ffox 4 compatible version of ubufox yet ;)
[14:12] <chrisccoulson> (i just saw your bug report)
[14:13] <chrisccoulson> it's still waiting on review by asac ;)
[14:13] <bcurtiswx> GNOME Menu's are broken :(
[14:13] <mterry> chrisccoulson, I figured it was something simple like that.  But I didn't see any other bug reports, so thought maybe I was unique
[14:13] <bcurtiswx> Unity + GNOME3 PPA
[14:14] <chrisccoulson> mterry, there is another bug report too, but reported for a different problem caused by the lack of ubufox
[14:16] <htorque> bcurtiswx, maybe bug 690717?
[14:16] <ubot2> Launchpad bug 690717 in unity (Ubuntu) "clicking for menus makes the unity bar/menu bar dissappear (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/690717
[14:16] <seb128> weird that people start getting that
[14:16] <seb128> neither compiz or unity changed
[14:17] <seb128> htorque, do you get it all the time?
[14:17] <seb128> or does restarting compiz fix it?
[14:17] <htorque> seb128, yes
[14:17] <bcurtiswx> it happens with all menus, even right clicking on the desktop doesn't show a menu, although it is there.. if i click in the area where it _should_ be then I get something to show up or happen
[14:17] <htorque> seb128, wait
[14:17] <seb128> htorque, does it happen in a GNOME session?
[14:17] <seb128> bcurtiswx, does it happen with any application?
[14:18] <htorque> seb128, compiz start seems to fix it
[14:18] <htorque> *restart
[14:18] <seb128> k, same thing njpatel_ was discussing earlier
[14:18] <bcurtiswx> i'll try a restart
[14:18] <seb128> it's weird still because compiz didn't change recently
[14:18] <seb128> I'm wondering if that could be the gtk update from yesterday
[14:19] <seb128> is that limited to gtk softwares?
[14:19] <seb128> or is firefox or qt doing the same?
[14:19] <bcurtiswx> seb128, yes messing with compiz does "fix" it.. it shows menu's but now any window will appear on top of them
[14:20] <bcurtiswx> seb128, menu's do not show in firefox because the menu's are hidden behind it
[14:20] <seb128> ok, so it's not gtk specific
[14:20] <seb128> still would be nice to test something in qt
[14:20] <seb128> just to be sure
[14:22] <kenvandine> seb128, so based on recent gtk3 theming discoveries, it wouldn't a good idea to make the new gwibber client gtk3 only, right?
[14:22] <seb128> kenvandine, not before we sort the gtk3 question at the sprint
[14:22] <kenvandine> ok
[14:22] <kenvandine> thought so
[14:22] <kenvandine> i rewrote gwibber-preferences last night :)
[14:22] <hggdh> oh, cool, this is being discussed :-) I had to go back to classical desktop
[14:23] <seb128> kenvandine, in gtk3?
[14:23] <seb128> hggdh, you as well?
[14:23] <kenvandine> no, but vala
[14:23] <kenvandine> but had considered using some stuff that was gtk3 only
[14:23] <kenvandine> but i'll avoid that
[14:23] <hggdh> seb128: aye (no mouse button working on menus/dropdowns)
[14:24] <htorque> seb128, not seeing it in a GNOME session (w/o compiz)
[14:24] <kenvandine> also using gsettings now, instead of gconf
[14:25] <seb128> htorque, and with compiz?
[14:25] <seb128> htorque, hggdh: what did you guys upgrade when that started?
[14:27] <hggdh> seb128: not sure, this was (I think two days ago -- I had done some upgrades during the last two days, and only yesterday evening I reloaded
[14:27] <hggdh> seb128: will look at the dpkg history
[14:28] <seb128> hggdh, what was 2 days ago?
[14:28] <seb128> htorque, when did that start for you?
[14:28] <hggdh> seb128: two days ago I started updating without reloading (busy). Yesterday, after the last updates I rebooted, and found it)
[14:28] <htorque> seb128, not exactly sure, i guess it start yesterday morning-ish (i'm gmt -1)
[14:29] <htorque> *started
[14:29] <seb128> htorque, before 3pm your time?
[14:29] <seb128> htorque, can you check if you updated gtk before or after it started?
[14:30] <htorque> htorque, i'll have a look
[14:31] <hggdh> seb128: which pieces of gtk are you looking for?
[14:32] <seb128> hggdh, libgtk2.0-0
[14:33] <htorque> seb128, compiz (w/o running the unity plugin obviously) and classic session seem fine
[14:33] <hggdh> seb128: when I updated it (yeasterday @20:50 CST) I already had the issue
[14:33] <ari-tczew> seb128: could you look on bug 552718. it wasn't fixed upstream
[14:33] <ubot2> Launchpad bug 552718 in webkit (Ubuntu) (and 1 other project) "typo in enable XSS auditor (affects: 1) (heat: 13)" [Low,Fix committed] https://launchpad.net/bugs/552718
[14:34] <htorque> htorque, yeah, i updated gtk yesterday, i'm just not sure when i saw this the first time
[14:34] <hggdh> classical desktop with compiz is fine
[14:34] <dobey> kenvandine: what do you know about the new python-couchdb package?
[14:34] <ari-tczew> I'm merging webkit right now and I'm going this patch
[14:34] <ari-tczew> (include)
[14:34] <bcurtiswx> seb128, metacity shows menu's fine
[14:34] <htorque> seb128, ^^ (oops)
[14:34] <kenvandine> dobey, not much, i haven't touched it in quite a while
[14:34] <kenvandine> dobey, but i have been expecting an update to sponsor
[14:34] <seb128> hggdh, htorque: do you guys use some ppa or non official source?
[14:34] <kenvandine> from chad
[14:34] <dobey> kenvandine: ok
[14:35] <seb128> ari-tczew, it has been commited upstream see the url on the bug
[14:35] <seb128> ari-tczew, you are welcome to include the patch in the update you do
[14:35] <ari-tczew> seb128: then I don't know how it could be committed upstream, 1.2.5 doesn't have this change
[14:36] <htorque> seb128, only banshee daily, chromium daily, darktable unstable
[14:36] <seb128> it's likely not in the 1.2 serie but in trunk
[14:36] <seb128> htorque, ok
[14:36] <bcurtiswx> seb128, http://paste.ubuntu.com/544449/ if that helps at all
[14:36] <seb128> htorque, do you get the issue every time using unity?
[14:36] <seb128> bcurtiswx, ^ same for you
[14:37] <htorque> seb128, yes, every session start. and once i get the context menu on the desktop, it's fixed for the rest of the session
[14:37] <seb128> if that's the case can you try to downgrade gtk to the version from last week?
[14:37] <bcurtiswx> seb128, yes sir
[14:37] <seb128> just to rule that out
[14:37] <htorque> seb128, which packages would that be?
[14:37] <seb128> https://launchpad.net/ubuntu/+source/gtk+2.0/2.23.2-0ubuntu2
[14:37] <htorque> seb128, on it :)
[14:37] <seb128> basically libgtk2.0-0
[14:37] <seb128> you can probably just downgrade it
[14:38] <seb128> dpkg might not like it but it will not crash, just force it, restart your session and upgrade again to make dpkg happy
[14:38] <seb128> dpkg will probably want you to downgrade some of the others binaries
[14:38] <seb128> but that's not required
[14:38] <seb128> htorque, thanks
[14:39] <seb128> kenvandine, how busy are you?
[14:39] <kenvandine> depends on what you need?
[14:39] <hggdh> seb128: the only ppas I have do not impact here (ubuntu fonts, and another internal one)
[14:40] <kenvandine>  :-D
[14:40] <seb128> kenvandine, can you handle the dx stack gir1.0 to gir1.2 renames
[14:40] <kenvandine> sure
[14:40] <seb128> kenvandine, don't bother testing locally or waiting for the current build
[14:40] <seb128> kenvandine, just rename gir1.0 to gir1.2 in the control and rules
[14:40] <seb128> the .install
[14:40] <kenvandine> ok, so package renames
[14:40] <seb128> then add a Conflicts: gir1.0...
[14:40] <seb128> kenvandine, I'm uploading the bottom stack, just did gdk-pixbuf, gtk next
[14:41] <kenvandine> ok, is there one you have done already?
[14:41] <kenvandine> ok
[14:41] <seb128> kenvandine, I'm doing the GNOME stack
[14:41] <seb128> just do dx
[14:41] <seb128> dbusmenu, libindicate, json-glib
[14:41] <kenvandine> json-glib isn't dx :)
[14:41] <seb128> well I just added it
[14:41] <kenvandine> i can do it
[14:41] <seb128> be nice or I add another one :p
[14:41] <kenvandine> appindicator too
[14:41] <seb128> thanks ;-)
[14:41] <kenvandine> will do
[14:41] <seb128> I'm trying to get that through today
[14:42] <seb128> tomorrow is unity update day
[14:42] <bcurtiswx> seb128, btw after the compiz --replace the menu's show fine and stay above all other windows
[14:43] <htorque> seb128, downgrading libgtk alone didn't help, will try the rest
[14:46] <bcurtiswx> im gonna reboot and test the workaround of compiz --replace after a fresh reboot.. brb
[14:48] <bcurtiswx> Yes, workaround confirmed.  No menu's on reboot, with a compiz --replace the menu's work as expected.
[14:49] <seb128> bcurtiswx, ok thanks
[14:50] <htorque> seb128, the downgrade didn't change a thing :-/
[14:50] <seb128> ok, thanks
[14:50] <seb128> that rules out gtk
[14:50] <seb128> which is what I wanted to check
[14:51] <bcurtiswx> is there a command in terminal to search previous natty only versions of compiz ?
[14:51]  * joaopinto would like to have a working Unity for Christmas
[14:52] <htorque> seb128, will downgrade compiz to glibmainloop3-0ubuntu1 (i upgraded to -0ubuntu3 yesterday morning)
[14:53] <seb128> htorque, thanks, you did upgrade from 0ubuntu1?
[14:53] <seb128> or 2?
[14:53] <htorque> 1
[14:54] <kenvandine> seb128, should the girs still be gettings installed in /usr/lib/girepository-1.0 ?
[14:55] <bcurtiswx> htorque, what's the exact package name you're downgrading to ?
[14:56] <bcurtiswx> compiz=1:0.9.2.1+glibmainloop3-0ubuntu1 ?
[14:57] <kenvandine> seb128, should the girs still be gettings installed in /usr/lib/girepository-1.0 ?
[14:57] <seb128> kenvandine, yes, no change to the upstream build
[14:57] <kenvandine> ok
[14:57] <htorque> seb128, 0ubuntu1 works fine here
[14:57] <seb128> hum, great
[14:57] <htorque> bcurtiswx, yes, that one
[14:57] <seb128> htorque, what binary did you downgrade?
[14:58] <htorque> seb128, oh crap, all of them
[14:58] <seb128> htorque, why "crap"?
[14:59] <htorque> seb128, maybe it would have helped to just test parts ;)
[14:59] <seb128> no, I was wondering what to suggest to people
[14:59] <seb128> htorque, could you test is 0ubuntu2?
[14:59] <seb128> just to see which one broke
[14:59] <htorque> seb128, already downloading :)
[15:00] <seb128> htorque, thanks
[15:00] <njpatel> seb128, the issue with the menus, there was a compiz update last week, right?
[15:01] <njpatel> actually 44hours ago
[15:01] <seb128> njpatel, yes
[15:01] <seb128> njpatel, http://launchpadlibrarian.net/60658417/compiz_1%3A0.9.2.1%2Bglibmainloop3-0ubuntu2_1%3A0.9.2.1%2Bglibmainloop3-0ubuntu3.diff.gz
[15:01] <seb128> njpatel, that's the most recent one
[15:01] <njpatel> okay, so at least for me that somewhat matches when my menus started to go AWOL
[15:01] <seb128> njpatel, http://launchpadlibrarian.net/60625863/compiz_1%3A0.9.2.1%2Bglibmainloop3-0ubuntu1_1%3A0.9.2.1%2Bglibmainloop3-0ubuntu2.diff.gz
[15:02] <seb128> that's the previous one
[15:02] <njpatel> let me try and down grade and see what happens
[15:02] <seb128> njpatel, I don't see anything obvious that should break in those
[15:02] <seb128> njpatel, they "just" play with the profile to give you a clean one on upgrade
[15:03] <njpatel> seb128, yeah
[15:07] <htorque> seb128, upgraded from -1 to -3 - bad again, downgraded to -2, which is fine
[15:07] <seb128> ok, so it's -3
[15:07] <seb128> njpatel, http://launchpadlibrarian.net/60658417/compiz_1%3A0.9.2.1%2Bglibmainloop3-0ubuntu2_1%3A0.9.2.1%2Bglibmainloop3-0ubuntu3.diff.gz
[15:07] <seb128> njpatel, the bug is somewhere there
[15:07] <njpatel> htorque, this is menus going missing?
[15:08] <seb128> njpatel, yes
[15:08] <njpatel> okay
[15:08] <njpatel> let me do two things and then I'll look through that
[15:08] <seb128> njpatel, that's really weird, that command thing should act only once
[15:08] <htorque> njpatel, yes
[15:09] <seb128> htorque, thanks for testing
[15:09] <njpatel> yeah, thanks for testing
[15:10] <htorque> ouch, no wait!
[15:10] <htorque> -2 is bad too
[15:10] <htorque> i have opened the context menu during my first test -.-
[15:12] <njpatel> htorque, what is your test? (so I can do the same)
[15:13] <htorque> njpatel,  start a session and click on the messages indicator => no menu
[15:14] <htorque> njpatel, open the context menu on the desktop (right-click), click on the messages indicator => menu
[15:15] <njpatel> htorque, when you click on the messages menu, what happens if you bring your mouse down to where the menu is expected to be
[15:15] <njpatel> ?
[15:15] <njpatel> htorque, the error I'm seeing is menus start appearing behind windows (i.e. chromium/xchat menus)
[15:15] <njpatel> context menus*
[15:15] <njpatel> panel menus just don't show
[15:16] <Amaranth> njpatel: Or they show behind the desktop
[15:16] <njpatel> Amaranth, right
[15:16] <htorque> njpatel, i see the highlight but no menu
[15:16] <chrisccoulson> oh, i've been getting that too, but i wasn't sure if it was just me ;)
[15:16] <njpatel> htorque, okay, even when hovering down where it should be....so it seems like the same issue
[15:17] <seb128> chrisccoulson, can you try downgrading compiz as well?
[15:17] <njpatel> chrisccoulson, on normal context menus as well as panel?
[15:17] <htorque> njpatel, like here for "File": http://launchpadlibrarian.net/60701746/Screenshot-1.png
[15:17] <chrisccoulson> njpatel, i've only noticed it on the panel
[15:17] <chrisccoulson> seb128 - yeah, will try that in a bit
[15:17] <seb128> thanks
[15:17] <njpatel> htorque, right, has it occured in any context menu inside an application for you?
[15:17] <htorque> the initial nautilus menu after a session start doesn't seem to react at all (FIle Edit View Places Help)
[15:18] <njpatel> (instead of panel menus)
[15:18] <chrisccoulson> i don't even have compiz after a session start :(
[15:18] <njpatel> chrisccoulson, I've seen that too but might not be compiz related and a unity bug
[15:18] <htorque> njpatel, yes
[15:18] <njpatel> htorque, okay, thank god
[15:18] <htorque> the only context menu that shows up is the one on an empty desktop
[15:18] <njpatel> htorque, I spent an hour yesterday thinking my new panel code had broken context menus in Compiz :)
[15:19] <seb128> Riddell, can you do another round of gir NEWing for me? we need at least gdk-pixbuf to get gtk next
[15:19] <seb128> Riddell, then we should be able to rebuild the remaining bits
[15:19] <htorque> njpatel, and after that showed up, menus & co seem to be fixed for the rest of the session
[15:20] <njpatel> htorque, hmm, okay
[15:20] <njpatel> htorque, mine seems to occur half way during a session
[15:21] <htorque> njpatel, i will again test compiz 0ubuntu1, but it seems fine
[15:21] <cyphermox> is there a know issue with drop-downs in compiz right now? With compiz / unity running the combo boxes would never show their lists, which works fine if I start metacity instead
[15:21] <seb128> njpatel, htorque: kirkland confirmed that downgrading fixes the issue as well on his box
[15:22] <njpatel> seb128, what version to downgrade to?
[15:22] <seb128>  https://launchpad.net/ubuntu/+source/compiz/1:0.9.2.1+glibmainloop3-0ubuntu1
[15:22] <seb128> njpatel, ^ that's the one I asked him to try
[15:23] <seb128> htorque, did you valide if 0ubuntu2 has the issue or not?
[15:24] <htorque> seb128, it definitely has the issue
[15:24] <seb128> ok
[15:25] <seb128> njpatel, so it seems to be http://launchpadlibrarian.net/60625863/compiz_1%3A0.9.2.1%2Bglibmainloop3-0ubuntu1_1%3A0.9.2.1%2Bglibmainloop3-0ubuntu2.diff.gz
[15:25] <njpatel> seb128, okay, so I'm downgrading and rebuilding unity, will report back in a bit
[15:25] <seb128> njpatel, no need to rebuild unity
[15:25] <htorque> with -1 i still see the initial nautilus menu (File Edit View Places Help) after a session start not responding to clicks at all, but that seems to be a different bug then
[15:26] <seb128> htorque, do you see the indicators?
[15:27] <htorque> seb128, with -1 everything else is fine - i start a program, i can open the menus, the context menus, the indicator menus - it's just that one nautilus menu right after a session start
[15:27] <seb128> ok
[15:27] <seb128> I never tried to use that one directly I've to admit
[15:27] <seb128> but that seems a different issue indeed
[15:27] <htorque> seb128, it doesn't even show a highlight, will open a new report
[15:27] <njpatel> seb128, it's my local copy, just want to make 100% sure
[15:28] <seb128> njpatel, ok
[15:28] <htorque> seb128, do you have an idea which package i should this report against?
[15:28] <njpatel> okay, so it's running, let's see how it goes
[15:28] <seb128> htorque, unity?
[15:29] <htorque> seb128, good, thanks!
[15:50] <bcurtiswx> Well, since I have a final exam this afternoon (EST) then I'm going to head off for the rest of the day.  I wish everyone a happy holidays (since I probably won't be on to catch all of ya before you leave) and a great new years.
[15:51] <bcurtiswx> Goodbye
[15:51] <seb128> bcurtiswx, ok, thanks, you as well!
[15:52] <seb128> cyphermox, re
[15:52] <seb128> cyphermox, try downgrading compiz
[15:57] <njpatel> seb128, htorque tested with my unity and yes, downgrading definitely fixes it for me
[15:57] <seb128> njpatel, ok, great
[15:58] <cyphermox> seb128, thanks
[15:59] <cyphermox> it's not hugely problematic, but I see I also can't click the indicators or global menu, probably related
[15:59] <Riddell> seb128: someone seems to have approved the gir packagse
[15:59] <seb128> Riddell, yeah sorry I pinged jdstrand meanwhile because I wanted to catch the publisher run
[15:59] <seb128> he just did it
[15:59] <seb128> Riddell, thanks ;-)
[16:05] <seb128> njpatel, so, what's next?
[16:05] <seb128> njpatel, should I just drop the diff from that upload?
[16:06] <njpatel> seb128, seeing as didrocks is away, probably yeah
[16:06] <seb128> njpatel, hum, ok
[16:06] <seb128> njpatel, btw the upload was to workaround https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/690239
[16:06] <ubot2> Launchpad bug 690239 in glib2.0 (Ubuntu) "hang in g_spawn_sync and select() (affects: 1) (heat: 6)" [Undecided,New]
[16:07] <seb128> which is a weird bug as well
[16:07] <Amaranth> Did the messaging indicator lose evolution support?
[16:07] <seb128> gdbus hanging in a sync call
[16:07] <seb128> Amaranth, no
[16:07] <Amaranth> Mine just shows Chat and Setup broadcast account
[16:07] <seb128> njpatel, well, he got compiz hanging this way on session start
[16:07] <njpatel> seb128, yeah, it was something to do with no session bus being available
[16:08] <seb128> njpatel, well the dbus-launch call should not hang in a select
[16:08] <seb128> it's weird
[16:08] <njpatel> oh, I agree
[16:08] <njpatel> seb128, there was a bug in RH bugzilla about it
[16:08] <njpatel> I don't have the link right now, though
[16:08] <seb128> right, https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=654027
[16:09] <seb128> well the rh bug is about the warning, not a hang
[16:09] <njpatel> oh
[16:10] <joaopinto> I am currently experiencing bug 439448, is there something I can do to debug or collect some data ?
[16:10] <ubot2> Launchpad bug 439448 in gnome-panel (Ubuntu Natty) (and 7 other projects) "Visual corruption affecting several panel applets (affects: 549) (dups: 116) (heat: 2776)" [Medium,Triaged] https://launchpad.net/bugs/439448
[16:10] <Amaranth> oh, I seem to have lost some packages in the ubuntu-desktop Recommends, reinstalling now
[16:10] <Amaranth> oops
[16:11] <Amaranth> Including evolution-indicator :)
[16:11] <joaopinto> it's the first time I am getting this bug on this newer hardware :(
[16:15] <nessita> james_w: hi there. Are you the person to ask about bzr merge-upstream?
[16:15] <james_w> hi nessita, indeed I am
[16:16] <nessita> james_w: good. Quick question, I'm getting http://pastebin.ubuntu.com/544482/ but I can workaround the error using --version
[16:17] <nessita> james_w: is that a regression bug (ie shall I report) or it used to work for me without the --version by chance?
[16:17] <james_w> nessita, by chance I think
[16:18] <james_w> you need the --version before the version number
[16:18] <nessita> james_w: ok then, thanks!
[16:18] <james_w> np
[16:52] <seb128> Riddell, hum, did you new atk etc to main?
[16:52] <seb128> the gtk build failed to get atk, it should be published though
[16:54] <Riddell> should have done, always possible I missed one of course
[16:56] <seb128> Riddell, can you check for gir1.2-atk-1.0? sorry but I'm having ssh issues to the dc and it seems the web ui will not let promote a binary
[16:57] <seb128> this box is in a weird state, I should perhaps restart
[16:57] <seb128> gnome-keyring broken?
[17:01] <Riddell> 2010-12-16 17:01:16 INFO    'gir1.2-atk-1.0-1.32.0-2/universe/libs/OPTIONAL' binary overridden in natty/i386
[17:01] <Riddell> seb128: fixed
[17:01] <seb128> Riddell, thankyou!
[17:08] <ari-tczew> could someone look on ftbfs in bug 691104 ?
[17:08] <ubot2> Launchpad bug 691104 in webkit (Ubuntu) "Merge webkit 1.2.5-2.1 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/691104
[17:19] <micahg> ari-tczew: FYI, there's no value added in the merge, so there shouldn't be a need to rush
[17:19] <ari-tczew> micahg: no? why?
[17:19] <ari-tczew> micahg: let me upload a branch
[17:20] <micahg> ari-tczew: I was just saying that since most people here are about to go on holiday until the end of the year
[17:21] <ari-tczew> micahg: debian has added a couple of patches fix some CVEs. now what do you think?
[17:22] <micahg> ari-tczew: apologies, you are correct
[17:23] <ari-tczew> micahg: heh, what a lack of confidence
[17:45] <nessita> would anyone be able to sponsor https://code.launchpad.net/~nataliabidart/ubuntu/natty/ubuntu-sso-client/ubuntu-sso-client-1.1.7/+merge/43939 and https://code.launchpad.net/~nataliabidart/ubuntu/maverick/ubuntu-sso-client/ubuntu-sso-client-1.0.8/+merge/43940 ?
[17:45] <nessita> Is the same change applied to maverick and natty
[17:49] <seb128> nessita, I've other things to finish before leaving now but I will do it tomorrow morning if nobody did
[17:50] <nessita> seb128: awesome, thanks!
[18:07] <seb128> ok, I need to go
[18:07] <seb128> the new gir should be newed by jdstrand when they are built
[18:08] <seb128> there is still a bunch of rebuilds which will be required
[18:08] <seb128> libubuntuone like
[18:08] <seb128> libwnck, totem-pl-parser
[18:08] <seb128> then some applications and gtk3 libs
[18:08] <seb128> language-selector, apport
[18:08] <seb128> kenvandine, mterry, if you want to continue on those feel free
[18:08] <seb128> no need to test build, just change gir1.0 to gir1.2 in the control and rules
[18:09] <seb128> rename the .install
[18:09] <seb128> conflicts on the old name
[18:09] <seb128> upload
[18:09] <seb128> they will depwait and build ;-)
[18:09] <seb128> need to go
[18:09] <seb128> be back later!
[18:16] <kenvandine> mterry, i did libwnck
[18:16] <mterry> kenvandine, k.  I can pick up the bottom two: language-selector and apport
[18:17] <kenvandine> ok, doing totem-pl-parser now
[18:33] <njpatel> kenvandine, is there a new indicator-network in the pipeline that doesn't depend on the old dbusmenu-gtk?
[18:33] <njpatel> it's breaking unity's panel service
[18:34] <kenvandine> njpatel, humm
[18:34] <kenvandine> it got rebuilt!
[18:34]  * kenvandine checks
[18:34] <kenvandine> there is a new release coming today
[18:34] <kenvandine> but i did rebuild that
[18:36] <njpatel> kenvandine, ldd on it shows libdbusmenu-gtk1 linkage
[18:36] <njpatel> I think I have latest 0.3.0-0ubuntu1
[18:36] <kenvandine> oh... interesting
[18:37] <kenvandine> 0.3.1-0ubuntu3
[18:37] <njpatel> let me make sure
[18:37] <kenvandine> is the latest
[18:37] <kenvandine> but it isn't built for amd64 yet!
[18:37] <njpatel> urgh
[18:37] <njpatel> ooooh
[18:37] <njpatel> :)
[18:37] <kenvandine> that was a week ago
[18:37] <kenvandine> looks like someone kicked off a rebuild though
[18:37] <kenvandine> it is building right now
[18:37] <kenvandine> funny timing
[18:37] <kenvandine> :)
[18:37] <njpatel> sweet
[18:37] <njpatel> right :)
[18:38]  * njpatel is in a problem
[18:38] <njpatel> I shoudl just do a bzr bd and get indicator-network I guess
[18:40] <kenvandine> the deb is done
[18:41] <kenvandine> https://edge.launchpad.net/ubuntu/+source/indicator-network/0.3.1-0ubuntu3/+build/2090025
[18:41] <kenvandine> njpatel, ^^
[18:41] <kenvandine> it is "uploading"
[18:41] <kenvandine> so the deb should show up any minute
[18:47] <njpatel> sweet
[18:57] <njpatel> come on....upload!
[19:16]  * mterry takes gnome-games for gir change
[19:19] <ari-tczew> mterry: could you take a look on webkit ftbfs? probably also gir issue. bug 691104
[19:19] <ubot2> Launchpad bug 691104 in webkit (Ubuntu) "Merge webkit 1.2.5-2.1 (main) from Debian unstable (main) (affects: 1) (heat: 10)" [Wishlist,New] https://launchpad.net/bugs/691104
[19:22] <mterry> ari-tczew, k, will check
[19:51] <mterry> ari-tczew, you tricked me, webkit takes forever to build  :)
[19:55] <Amaranth> mterry: oh man, like an hour
[19:57] <ari-tczew> mterry: it was a trap :)
[20:00] <ari-tczew> seb128: did you want to give an ACK for bug 691032 ?
[20:00] <ubot2> Launchpad bug 691032 in luatex (Ubuntu) "Sync luatex 0.65.0-1 (main) from Debian experimental (main) (affects: 1) (heat: 8)" [Wishlist,Confirmed] https://launchpad.net/bugs/691032
[20:02] <seb128> ari-tczew, yes
[20:02] <seb128> I got sidetracked and forgot to comment it seems though
[20:02] <seb128> kenvandine, mterry: thanks for the gir uploads
[20:03] <kenvandine> seb128, got anymore that need doing?
[20:03] <kenvandine> i might be able to squeeze a couple more in
[20:05] <seb128> kenvandine, libubuntuone?
[20:05]  * mterry grabs libunique
[20:05] <kenvandine> libubuntuone doesn't have any girs
[20:05] <kenvandine> which actually seems weird
[20:06] <mterry> I see gir1.0-ubuntuone-1.0 in my apt-cache
[20:06] <kenvandine> not in the control file
[20:06] <kenvandine> humm
[20:06] <seb128> $ apt-cache showsrc gir1.0-ubuntuone-1.0 | grep Binary
[20:06] <seb128> Binary: python-ubuntuone, libubuntuone1.0-cil, libubuntuone1.0-cil-dev, libubuntuone-1.0-1, libubuntuone-dev, gir1.0-ubuntuone-1.0
[20:06] <seb128> kenvandine, ?
[20:06] <kenvandine> oh.
[20:06] <kenvandine> this branch is very old
[20:07] <kenvandine> we need to kill off the branch
[20:07]  * kenvandine does libu1
[20:07] <seb128> thanks
[20:12]  * mterry grabs libpeas
[20:13] <seb128> libseed needs a rebuild as well
[20:14] <mterry> ok, got it
[20:14] <seb128> kenvandine, libgwibber can be yours ;-)
[20:15] <kenvandine> yeah :)
[20:15] <seb128> ubuntuone-client as well
[20:15] <micahg> seb128: tangentially related to libseed, do you see any issue with dropping gjs since we dropped gnome-shell?
[20:15] <seb128> micahg, no
[20:15] <micahg> seb128: ok, I'll take care of it then, thanks
[20:16] <seb128> thank you
[20:16] <seb128> mterry, can we sync gtksourceview3 on debian?
[20:16] <seb128> or do we have a diff?
[20:16] <ari-tczew> mterry: do you building current webkit or my merge?
[20:16] <mterry> seb128, um, have they pushed to experimental yet?  If so, I don't believe we have a diff...
[20:16] <mterry> ari-tczew, your merge
[20:17] <seb128> mterry, http://ftp.debian.org/debian/pool/main/g/gtksourceview3/gtksourceview3_2.91.2-1.dsc
[20:17] <mterry> seb128, though we may have a diff now if they haven't done the gir1.2 thing
[20:17] <mterry> seb128, ok, checking
[20:17] <seb128> mterry, they did
[20:17] <seb128> mterry, that's why I'm asking ;-)
[20:17] <seb128> I can just do the sync if we have no diff
[20:18] <ari-tczew> if package has DEPWAIT due to libvala-dev, which one should be this B-D replaced for?
[20:19] <mterry> seb128, without reviewing actual source changes to confirm, all my changes are in his changelog
[20:19] <mterry> seb128, so there should be no delta
[20:19] <seb128> mterry, ok, let's just sync
[20:19] <seb128> we can fix if required
[20:21] <seb128> mterry, done
[20:21]  * mterry grabs evince
[20:25] <ari-tczew> is change libvala-dev => libvala-0.12-dev is a correct change?
[20:26] <seb128> if it builds yes
[20:28] <ari-tczew> I wanted to do this change on mdbus, but there is a bug 618809
[20:28] <ubot2> Launchpad bug 618809 in vala-terminal (Ubuntu) (and 21 other projects) "libvala-dev -> libvala-0.10-dev transition (affects: 1) (heat: 14)" [Low,Fix released] https://launchpad.net/bugs/618809
[20:30]  * mterry grabs launchpad-integration
[20:41]  * seb128 does dee
[20:45] <mterry> seb128, my launchpad-integration and libunique changes didn't go through, because I can't upload to main.  want to help me out?  let me point you to my changes
[20:45] <seb128> mterry, sure
[20:45] <mterry> seb128, https://code.launchpad.net/~ubuntu-desktop/launchpad-integration/ubuntu for launchpad-integration
[20:47] <mterry> seb128, http://pastebin.ubuntu.com/544600/plain/ for libunique
[20:48] <mterry> I'm so used to having permission to the things I work on, I forget what's in what bucket sometimes
[20:48] <seb128> mterry, those should probably be added to the desktop set
[20:48] <seb128> do you want to ping cjwatson about them?
[20:48] <seb128> sponsoring those updates but for next time
[20:49] <mterry> seb128, I think you just did  :)  cjwatson: can launchpad-integration and libunique be added to the ubuntu-desktop set?
[20:52]  * mterry grabs gnome-shell, which will take some time -- I have pending changes for it for libgirepository, have to see how buildable it is right now
[20:52] <seb128> mterry, wait
[20:52] <seb128> mterry, that one has been removed from natty
[20:53] <mterry> seb128, oh...  OK
[20:53] <seb128> mterry, you can upload it to the GNOME3 ppa if you want though
[20:53] <mterry> seb128, hadn't noticed  :)
[20:53] <mterry> seb128, OK, but I'll put it on the backburner for now
[20:53] <seb128> mterry, the rational is that it needs GNOME3 to work
[20:54] <seb128> mterry, lpi and libunique uploaded
[20:54] <micahg> mterry: if you have a branch, can you push it somewhere, I'd like to stage it in the GNOME3 PPA and am willing to help with it
[20:54] <mterry> seb128, thanks
[20:54] <mterry> micahg, ok, hold on
[20:54] <seb128> mterry, thank *you* ;-)
[20:54] <micahg> mterry: not urgent for right now, just when you get a chance
[20:58] <cyphermox> seb128, could you look at https://code.edge.launchpad.net/~mathieu-tl/evolution-data-server/lp690178-lp689771/+merge/43922 please? it's the backports of e-d-s fixes from git.
[20:58] <seb128> cyphermox, ok, thanks
[20:59] <kenvandine> seb128, of course libgwibber won't build on natty now...
[20:59]  * kenvandine is fixing :)
[20:59] <seb128> kenvandine, I open a bug about that and you told me it was fixing in trunk last week?
[20:59] <kenvandine> it is
[21:00] <mterry> micahg, lp:~mterry/ubuntu/natty/gnome-shell/wip
[21:00] <kenvandine> but it isn't really releasable
[21:00] <micahg> mterry: thanks
[21:00] <kenvandine> i am working on getting it ready for a release
[21:00]  * seb128 grrrr at kenvandine
[21:00] <kenvandine> but in the meantime i am fixing the build for now
[21:00] <kenvandine> s/i am/i was/
[21:00] <kenvandine> :)
[21:00] <seb128> sorry
[21:00] <mterry> micahg, that doesn't build right now (especially since I just made the gir1.2 change), but it has good fixes
[21:00] <kenvandine> no worries
[21:00] <seb128> just got my dee upload rejected
[21:01] <seb128> you didn't commit your last revision or push it
[21:01] <kenvandine> oh?
[21:01]  * seb128 fixes the vcs and reupload
[21:01] <kenvandine> sigh...
[21:01] <micahg> mterry: should I just propose merges into your branch?  would you mind being my sponsor for the GNOME3 PPA?
[21:01] <seb128> kenvandine, no worry ;-)à
[21:01] <seb128> -à
[21:01] <kenvandine> surprised i was the last to touch it :)
[21:01] <seb128> kenvandine, thanks for fixing libgwibber!
[21:01] <mterry> micahg, sure, sounds good
[21:01] <kenvandine> been a while
[21:01] <kenvandine> seb128, has he fixed the soname thing?
[21:02] <seb128> kenvandine, you renamed the gir, http://launchpadlibrarian.net/59882123/dee_0.4.2-0ubuntu4_0.4.2-0ubuntu5.diff.gz
[21:02] <micahg> mterry: thanks, probably won't get to it until EOY, but I would like to make sure it works
[21:02]  * kenvandine was hoping for a new version of dee in time for spare time hacking tonight :)
[21:02] <seb128> kenvandine, I will deal with the unity updates tomorrow
[21:02] <kenvandine> cool
[21:02] <seb128> but I think we agreed on using Breaks and not changing the soname
[21:02] <kenvandine> sigh.. dh_autoreconf isn't happey
[21:02] <seb128> since mickael wants to break the abi several time this cycle and only unity uses it
[21:02] <kenvandine> config.status: error: po/Makefile.in.in was not created by intltoolize.
[21:03] <kenvandine> seb128, libgwibber, the new gwibber client, and gwibber-service will all use it real soon
[21:03] <seb128> kenvandine, then we can try to convince mickael about stability ;-)
[21:04] <kenvandine> seb128, any idea why dh_autoreconf makes it complain about po/Makefile.in.in?
[21:04] <seb128> no, I had similar issues in the past but never debugged, I rolled back to autoreconf patches to workaround it
[21:04] <kenvandine> :/
[21:05] <seb128> if you figure what's wrong let me know
[21:05] <kenvandine> :)
[21:05]  * kenvandine yells about autotools
[21:06] <mterry> kenvandine, I've hit that and fixed it...  I believe...  Can't remember what I did.  Let me think
[21:06] <kenvandine> cool
[21:07] <seb128> would be if he did remember :p
[21:07]  * seb128 bouh at mterry
[21:07] <seb128> ;-)
[21:07] <mterry> :)
[21:08] <kenvandine> got it
[21:08] <kenvandine> export AUTOPOINT = true
[21:08] <kenvandine> in rules
[21:08] <mterry> kenvandine, yeah that sounds familiar
[21:08] <seb128> kenvandine, can you explain?
[21:09] <seb128> I should learn what autopoint is before asking I guess :p
[21:09] <kenvandine> it tells dh_autoreconf to not run autopoint
[21:09] <mterry> seb128, that stops autoreconf from running autopoint, which initializes the po directory
[21:09]  * kenvandine doesn't really know what autopoint is either
[21:09] <kenvandine> i think it copies files for gettext
[21:10] <mterry> kenvandine, seb128: yeah, it copies Makefile.in.in (and others) into po.  But so does intltoolize, so that's why the error
[21:10] <popey> r
[21:10] <mterry> I think
[21:10] <kenvandine> something like that
[21:11] <kenvandine> so export AUTOPOINT = true tells it to skip that
[21:11] <cyphermox> ah, kenvandine, you probably just gave me the best clue to fix the emerillon build I'm struggling with now ;)
[21:11] <kenvandine> doesn't explain why it fails
[21:11] <kenvandine> :-D
[21:11]  * kenvandine hugs dh_autoreconf
[21:11] <cyphermox> heh,
[21:11]  * cyphermox stabs dh_autoreconf
[21:11] <cyphermox> a clear case of DWIMNWITY
[21:12] <cyphermox> (do what I mean, not what I tell you)
[21:13] <seb128> kenvandine, nice catch
[21:33] <cjwatson> mterry: can you mail me so I don't forget?  well past end of day here
[21:34] <cjwatson> mterry: (in general, I'd really prefer to be mailed this stuff rather than mentioning it on IRC - IRC sucks for queueing so I have the choice between doing things immediately or forgetting)
[21:42] <cyphermox> anyone could try out emerillon as it currently is in the repo and tell me if they get anything other than a grey map that never changes?
[21:43] <cyphermox> I'm seeing some maps getting downloaded here, but it looks like libchamplain is borked in some way, and never actually manages to draw the pngs
[22:08] <mdeslaur> anybody else seeing bug 632412 with appmenu installed?
[22:08] <ubot2> Launchpad bug 632412 in gnome-terminal (Ubuntu) "Windows 2 rows shorter than it should be (affects: 2) (dups: 1) (heat: 38)" [Low,Confirmed] https://launchpad.net/bugs/632412
[22:10] <kenvandine> seb128, i am going to have to just release the new libgwibber with a soname bump
[22:10] <kenvandine> i'll try to do it later tonight
[22:10] <kenvandine> seb128, symbols are going to be getting changed
[22:11] <kenvandine> a bug in g-ir-scanner before was creaking stuff that should have been in the gwibber_gtk namespace as gwibber_
[22:11] <kenvandine> so rebuilding on natty is going to remove those
[22:12] <seb128> kenvandine, no hurry, the gir at not used by anything right?
[22:12] <seb128> they have no rdepends
[22:12] <kenvandine> nope
[22:13] <kenvandine> but this will change the api, so i need the soname change
[22:13] <kenvandine> although nothing is consuming that api either
[22:13] <kenvandine> so maybe i shouldn't worry about that...
[22:14] <kenvandine> it's only stuff in libgwibber-gtk that will be changing
[22:14] <kenvandine> which has no rdepends right now
[22:15] <kenvandine> i need to run for now, bbl
[22:17] <seb128> ok
[22:17] <seb128> well the no rdepends was to say there is no hurry to transition the girs
[22:17] <seb128> you can do that tomorrow or next week
[22:17] <kenvandine> ok, well i will have a libgwibber release ready before the weekend :)
[22:18] <kenvandine> i have been trying to get it in shape for release for a couple days, and keep getting distracted :)
[22:41] <seb128> hum
[22:41] <seb128> mterry, I'm fixing the apport build issue
[22:44] <seb128> mterry, it was a commit missing in the vcs from the previous upload it seems
[22:44] <seb128> robert_ancell, there?
[22:45] <robert_ancell> seb128, hey
[22:45] <seb128> robert_ancell, hello
[22:45] <seb128> robert_ancell, how are you?
[22:45] <robert_ancell> seb128, good
[22:45] <seb128> robert_ancell, we got mostly through the gir abi transition
[22:45] <robert_ancell> nice :)
[22:45] <seb128> robert_ancell, can you review
[22:45] <seb128> https://code.edge.launchpad.net/~mathieu-tl/xchat-gnome/update-to-0.26.2+git/+merge/43283
[22:46] <robert_ancell> I didn't get around to looking at it
[22:46] <seb128> https://code.edge.launchpad.net/~mathieu-tl/evolution-data-server/lp690178-lp689771/+merge/43922
[22:46] <seb128> during your day
[22:46] <seb128> they should be ready to upload
[22:46] <seb128> cyphermox should really apply for upload rights
[22:46] <robert_ancell> seb128, ok.  (btw they show up in versions now)
[22:46] <seb128> I just finished with gir stuff and I don't feel like starting new reviews
[22:47] <seb128> robert_ancell, oh right, that's why I said hello to you yesterday
[22:47] <robert_ancell> and they look annoying so I'm motivated to do the reviews :)
[22:47] <seb128> or rather this morning, but seemed you left already
[22:47] <seb128> that's really nice
[22:47] <seb128> thanks for that
[22:47] <robert_ancell> oh, I left my computer on
[22:47] <seb128> I noticed it and went "waouh, that's nice"
[22:47] <seb128> ;-)
[22:48] <seb128> robert_ancell, the xchat-gnome one doesn't show there but I think he just forgot to set it back to needs review
[22:48] <seb128> the vte one applies to an old version and can probably be dropped
[22:48] <seb128> robert_ancell, otherwise debian uploaded clutter-glx-1.0 as clutter-glx
[22:48] <robert_ancell> soon I'm going to be able to work without leaving that page ever :)
[22:49] <seb128> if you want to review and see if we can sync it
[22:49] <seb128> lol
[22:49] <seb128> they have a newer clutter as well
[22:49] <seb128> I think that was it from my info dump for the day ;-)
[22:49] <seb128> ok, done with work
[22:50] <seb128> I'm still hanging around a bit on IRC if you have anything to discuss
[22:50] <seb128> cleaning some emails as well
[22:50] <robert_ancell> go on holiday!!
[22:50] <seb128> heh
[22:50] <seb128> still one work day
[22:50] <seb128> it's only thursday there
[22:50] <seb128> tomorrow is going to be busy
[22:50] <seb128> didrocks is off and I've to deal with the last unity drop from 2010...
[22:50] <seb128> ;-)
[22:50] <seb128> let's hope they don't break things
[22:51] <seb128> but after that oh yeah
[22:52] <seb128> brb
[22:52] <robert_ancell> seb128, I thought you were off Friday?
[22:53] <Amaranth> seb128: So I should yell at you if things fall apart tomorrow? :)
[22:54] <seb128> robert_ancell, I did take the fridays off mostly for some weeks yes
[22:55] <seb128> robert_ancell, but didrocks is moving to his new flat this week and pitti is away already and someone had to deal with the unity update
[22:55] <seb128> so I decided to still work tomorrow to finish things before holidays
[22:55] <robert_ancell> ah ok
[22:56] <robert_ancell> seb128, btw, do you know much about langpacks?  I think pitti is the expert right?
[22:56] <seb128> I should have dumped it on you :p
[22:56] <seb128> he is
[22:56] <seb128> what do you want to know?
[22:56] <seb128> dpm knows about them a bit as well
[22:57] <robert_ancell> The Yelp translations don't work for the accessibility guide, I'm having a look now
[22:57] <seb128> they are not shipped in the langpacks?
[22:58] <robert_ancell> no, there is a broken link
[22:58] <robert_ancell> they are definitely in the gnome-user-doc source, so I'm guessing something is not including them in the langpack.  Could that be a backend issue?
[22:58] <seb128> /usr/share/locale-langpack/fr/LC_MESSAGES/gnome-user-docs-accessibility-guide.mo
[22:58] <seb128> in language-pack-gnome-fr-base
[22:59] <seb128> that's the maverick langpacks one
[22:59] <seb128> dunno if that got broken in natty
[22:59] <seb128> or with some update
[23:00] <robert_ancell> is /usr/share/gnome/help/gnome-access-guide/fr_FR/gnome-access-guide.xml a broken symlink for you?
[23:00] <robert_ancell> this is in maverick
[23:00] <seb128> no
[23:00] <seb128> it's a real file on disk
[23:00] <seb128> ups
[23:00] <robert_ancell> what package is providing that file?
[23:00] <seb128> I don't have that file in fact
[23:01] <seb128> gnome-user-guide-fr: /usr/share/gnome/help/gnome-access-guide/fr/gnome-access-guide.xml
[23:01] <seb128> which is broken indeed
[23:02] <seb128> http://packages.ubuntu.com/search?searchon=contents&keywords=gnome-access-guide.xml&mode=exactfilename&suite=maverick&arch=any
[23:02] <seb128> seems langpacks are buggy for that indeed
[23:03] <seb128> check pkgbinarymangler
[23:03] <robert_ancell> langpacks are done server side right?
[23:04] <seb128> or langpack-o-matic
[23:05] <seb128> launchpad.net/~langpack-o-matic
[23:05] <seb128> that's the server code I think
[23:05] <seb128> pkgbinarymangler is the buildd one
[23:05] <robert_ancell> pkgbinarymangler appears to only do .mo files
[23:06] <seb128> ok, drop an email to pitti then
[23:06] <seb128> it's over my langpack clue ;-)
[23:06] <robert_ancell> thanks for the tips
[23:06] <seb128> yw
[23:51] <chrisccoulson> w00t - http://people.canonical.com/~chrisccoulson/Screenshot_004.png :)
[23:51] <chrisccoulson> sadly, i can't get it to work with tbird 3.1 yet though
[23:51] <micahg> chrisccoulson: is that a trunk nightly?
[23:52] <chrisccoulson> micahg - yeah
[23:52] <chrisccoulson> i don't know how i'm going to make it work with 3.1
[23:52] <chrisccoulson> my extension uses way too many unfrozen API's, and it doesn't even support being built against older gecko versions
[23:52] <chrisccoulson> so, i'm a bit stuffed atm ;)
[23:53] <micahg> chrisccoulson: ok, next weekend and the one after I have  long weekends so one of them I'll do thunderbird trunk packaging :)
[23:53] <chrisccoulson> i nearly started it tonight, until i realised that there are already 64-but trunk builds ;)
[23:54] <chrisccoulson> i want to get my other fixes in to unity, indicator-appmenu and dbusmenu really, so i can get this in the archive
[23:54] <chrisccoulson> it's basically fully working now :)
[23:55] <chrisccoulson> but i'm running local patches in other parts of the stack to make it work
[23:58] <micahg> chrisccoulson: well, I wish I could say there'd be a 3.3 for natty, but that seems up in the air
[23:59] <chrisccoulson> i don't think that's going to happen, but it would solve my problems ;)
[23:59] <chrisccoulson> i'm just going to have to provide 2 extensions
[23:59] <chrisccoulson> which sucks