[06:17] <didrocks> hey Mirv
[06:17] <didrocks> Mirv: can you have a look at bug #1075375, seems an upgrade issue
[06:17] <didrocks> would be nice to investigate it a little bit
[06:18] <Mirv> didrocks: ok, looking
[06:19] <didrocks> thanks :)
[08:34] <MCR1> duflu: Hi :) Thanx 4 the reviews. I've used the default color now: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1070297-no-possibility-to-change-background-outline-color/+merge/132500
[08:35] <duflu> MCR1: Hi. Yes, you don't need to tell me. I get notified immediately.
[08:35] <MCR1> duflu: ok, ack :) I thought you've had problems with the launchpad mail not notifying you ;), sry...
[08:37] <MCR1> mmrazik: Hi :) And thx 4 re-approval.
[08:37] <mmrazik> MCR1: no problem :)
[08:40] <MCR1> duflu: Thanks a lot also for the approval. Finally resizeinfo should be tuned 8-)
[08:51] <mmrazik> MCR1: don't worry about the recent failures. I'm taking care of that.
[08:51] <MCR1> mmrazik: thx a lot :)
[10:08]  * didrocks tries another way to deal with parallel and join jobs in jenkins, too hard to track in the API what is doing what
[14:46] <didrocks> mmrazik|afk: hey, to be able to merge https://code.launchpad.net/~mterry/bamf/inline-debian/+merge/132944, can you please remove the packaging branch for it? (and avoid running autoreconf as well)
[14:46] <didrocks> mmrazik|afk: once done, feel free to flip the swithc
[14:46] <didrocks> switch*
[14:47] <mmrazik> didrocks: Ok. I'll do the change and approve.
[14:47] <didrocks> mmrazik: thanks a lot :)
[14:55] <mhr3> didrocks, will you take care of approving all the inline-debian branches?
[14:56] <didrocks> mhr3: yeah, don't worry with that :)
[14:56] <didrocks> mhr3: I'm doing one after another first :)
[14:56] <mhr3> awesomeness
[14:56] <mmrazik> didrocks: it will take a moment. The job failed. The compiz inline stuff was merged manually and there is one hook which doesn't take the newly creted branch into accout
[14:56] <mhr3> thx :)
[14:56] <mmrazik> fginther is looking into it
[14:57] <mmrazik> but I'm tempted to merge this stuff manually (or after building just the proposed branch somewhere to check it really works)
[14:58] <didrocks> mmrazik: ok, thanks! keep me posted :)
[15:16] <mterry> mmrazik, hello!  I've been preparing various inline-debian/ branches for unity components that will need their recipes changed to stop pulling in an external packaging branch
[15:16] <mterry> mmrazik, notably so far, compiz and bamf
[15:17] <mmrazik> mterry: compiz is in. fginther is checking bamf
[15:17] <mmrazik> mterry: can you work with fginther on this? He is in US timezone so it should be simpler
[15:17] <mterry> mmrazik, OK
[15:21] <fginther> mterry, hello
[15:21] <mterry> fginther, hi!
[15:22] <fginther> mterry, just ping me as you get the branches ready, we may have to do these by hand for a bit
[15:22] <mterry> fginther, yup.  So I have several branches waiting to be approved, but I'll ping you once a human says they're OK.  Only pending branch in that state is bamf
[15:33] <didrocks> fginther: you did see my note about dropping running autoreconf for those before building the package, isn't it?
[15:34] <fginther> didrocks, no sorry I missed that. Thanks for updating
[15:35] <didrocks> fginther: yeah, so you need to: 1. remove the "external packaging bits", and 2. not installing extra rdepends and running autoreconf/creating tarballs anymore
[15:35] <didrocks> for those packages :)
[15:36] <fginther> didrocks, thanks
[15:36] <didrocks> yw, good luck!
[15:38] <gatox> hi, i'm trying to compile unity (after compiling nux, according to this guide: http://unity.ubuntu.com/getinvolved/development/unity/), but i'm always getting stuck at: http://paste.ubuntu.com/1337547/ can anyone please give me a hand?
[15:39] <didrocks> mterry: ok, looking again this afternoon (done a first pass to them this morning). All looks good to me (maybe some missing lenses, like the remote video scope one for instance or the music/file lenses). I assume that you tried them in a chroot to ensure you don't miss gnome-doc-tools and so on?
[15:39] <mterry> didrocks, yeah I've built all in a chroot
[15:40] <didrocks> mterry: rocking! Thanks :)
[15:40] <mterry> didrocks, I haven't gotten to all the lenses yet, yeah
[15:40] <mterry> didrocks, that's for this morning
[15:40] <didrocks> mterry: I just conditionnaly +1 one, but didn't change the switch, I'll let you coordinate with fginther :)
[15:40]  * mterry gets a flood of didrocks reviews in his inbox
[15:41] <mterry> didrocks, OK
[15:41] <didrocks> mterry: yeah, did the review this morning, but wanted to talk to you first :)
[15:41] <didrocks> mterry: thanks for the quick changes! :)
[15:41] <didrocks> mterry: getting the flood? you are subscribed to all merges now? :-)
[15:41] <didrocks> (even compiz? :p)
[15:42] <mterry> didrocks, no, just my merges
[15:42] <mterry> :)
[15:42] <didrocks> mterry: this is for this afternoon, right? ;-)
[15:42] <didrocks> I wonder if we have a team for that: all unity stack only + compiz
[15:42] <didrocks> mmrazik: do you know? ^
[15:45] <mterry> fginther, so the following branches are approved but need their jenkins recipe fixed: bamf, dee, libunity, nux, unity-asset-pool, unity-lens-applications, unity-lens-video
[15:45] <fginther> mterry, got it. I hope to have the recipe scripts fixed shortly
[15:54] <mmrazik|otp> didrocks: you mean for unity/compiz maintenance?
[15:54] <didrocks> mmrazik|otp: for the whole unity stack
[15:55] <mmrazik|otp> didrocks: it should be Stephen and his squad for 13.10
[15:55] <mmrazik|otp> err
[15:55] <mmrazik|otp> 13.04
[15:55] <mmrazik|otp> + some more people (like duflu)
[15:55] <didrocks> mmrazik|otp: sorry, I meant "team" as "launchpad team" where mterry can subscribe
[15:55] <mmrazik|otp> didrocks: I don't think so
[15:55] <didrocks> so that he receives all MR for this stack
[15:55] <mmrazik|otp> but unity-team and compiz-team should do it
[15:55] <didrocks> so the only option is to subscribe to every components?
[15:55] <mmrazik|otp> or maybe not..
[15:55] <didrocks> mmrazik|otp: can we add him to them?
[15:55] <mmrazik|otp> didrocks: I fear that is the case :-/
[15:55] <mterry> didrocks, I can always filter out
[15:56] <mterry> didrocks, I already have an extensive set of filters, what's 10 more
[15:56] <didrocks> mterry: as you prefer ;)
[15:56] <mmrazik|otp> mterry: if you need to be part of some teams just send me a list and I'll make it happen
[15:57] <mterry> mmrazik|otp, I think just unity-team and compiz-team
[15:57] <mmrazik|otp> mterry: ok
[16:08] <mterry> mmrazik|otp, and ~unity-lens-photos (does that really need a separate team?)
[16:09] <davidcalle> mterry, which team do you suggest, I can change it if needed.
[16:09] <mterry> davidcalle, the rest of the lens seem to use ~unity-team
[16:10] <davidcalle> didrocks, who can add people on ~unity-team?
[16:12] <mterry> davidcalle, apparently mmrazik|otp can
[16:12] <didrocks> davidcalle: pspmteam I guess, but mmrazik|otp would no more
[16:14] <mmrazik> yes, it is pspmteam (or whoever is member of that team)
[16:15] <mmrazik> mterry: only davidcalle can add you to unity-lens-photos
[16:16] <mmrazik> mterry: other than that you should be member of unity-team and compiz-team
[16:17] <davidcalle> mterry, didrocks, mmrazik, thanks. So unity-team should be set as the driver or maintainer of the project?
[16:17] <mmrazik> davidcalle: I actually don't know. If you are the maintainer then the team/owner is probably correct
[16:18] <mmrazik> I mean the current one
[16:18] <mterry> davidcalle, looking at https://launchpad.net/unity-lens-files ...
[16:18] <mterry> davidcalle, pspteam is maintainer, unity-team is driver and owner of trunk
[16:19] <mmrazik> but the pspmteam indicates PS/Canonical are maintaining and fully owning it
[16:19] <mmrazik> not sure if that is the case for unity-lens-photos
[16:19] <didrocks> mmrazik: it's a canonical project, so it should be unity-team
[16:19] <mmrazik> If we would do the same with lens-photos david would loose the right to upload to trunk
[16:19] <mmrazik> (I think)
[16:19] <davidcalle> mmrazik, it's not, I would be fine with it, as long as I'm still able to manage trunk, since I'm pretty much on my own with it
[16:20] <didrocks> davidcalle: yeah, but we need something like this for the automagic uploading model
[16:20] <mmrazik> didrocks: what do we need?
[16:21] <mmrazik> wouldn't it be enough if some bot/user is part of ~unity-lens-photos?
[16:21] <mmrazik> I actually start to be a bit confused :) So don't worry too much about my suggestions..
[16:21] <didrocks> mmrazik: I don't see why unity-lens-photos should be different from any other officially supported lens
[16:22] <didrocks> mmrazik: I'm all for consistency, so unity-team would make sense has the owner, or at least, being part of ~unity-lens-photos
[16:22] <didrocks> to have similar right without loosing david having rights on those
[16:22] <davidcalle> didrocks, that would work indeed, I'm adding unity-team to the photos lens team, unless someone adds me or the photos lens team to unity-team.
[16:23] <didrocks> davidcalle: let's do that for now :) I'm sure you will be soon in the unity-team, and then, we can revisit :)
[16:23] <mmrazik> the thing that concerns me is that unity-team has only canonical employees as members and I wouldn't be surprised if somebody is relying on that fact
[16:24] <didrocks> mmrazik: non virtual ppa, yeah, it's relying on that
[16:24] <mmrazik> yes... arm builds..
[16:28] <davidcalle> didrocks, mmrazik, ok, then I'm adding the unity-team to the photos lens team. Welcome, we have beer and cookies :)
[16:29] <didrocks> thanks davidcalle
[16:29] <davidcalle> didrocks, np
[16:30] <mterry> davidcalle, :)
[16:38] <mterry> fginther, unity-lens-photos also needs jenkins fixups
[16:38] <fginther> mterry, will add it to the list
[16:45] <MCR1> Hi :) Anyone able to drag launcher icons with recent trunk version of Unity ? (staging PPA/Quantal)
[16:45] <MCR1> Here Unity crashes immediately...
[16:46] <MCR1> & another question: Why is Compiz not updated anymore in unity-team/staging PPA ?
[16:47] <MCR1> Compiz is still on r3450, but latest should be r3453...
[16:48] <MCR1> sil2100: Can you help me with those questions above ^^ ?
[16:50] <sil2100> MCR1: let me read up
[16:51] <fginther> MCR1, the compiz switch to inline packaging is probably the culprit
[16:51] <fginther> the autolanding/dput scripts need some work to get this going again
[16:51] <MCR1> yes, I think so also as it is r3451...
[16:51] <fginther> fginther, I'm working on it
[16:51] <MCR1> fginther: Is someone working on that ?
[16:52] <MCR1> ah cool - great thanks :)
[16:52] <sil2100> MCR1: it seems you need to be patient ;)
[16:52] <MCR1> sil2100: Unfortunately patience is not something I have a lot of ;)
[16:53] <MCR1> sil2100: & I think reporting issues early is better than late...
[16:54] <MCR1> or never...
[16:54] <fginther> MCR1, sil2100: the jenkins autolanding server is down at the moment, so I can't give you much at the moment
[16:55] <MCR1> fginther: Thanks, no problem - just wanted to make sure someone's aware of it (even better if you are already fixing it...) 8-)
[16:56] <fginther> MCR1, no problem. sometimes these things do slip through...
[17:05] <conscioususer> larsu: ping
[17:06] <larsu> conscioususer, hey
[17:06] <conscioususer> larsu: have some mins? I need some extra help with gtkapplication :)
[17:07] <larsu> conscioususer, I found the problem to the bug you filed yesterday: wait 5 seconds before restarting your app, then it works :)
[17:07] <larsu> (don't ask)
[17:07] <larsu> (yes, a fix is coming)
[17:07] <larsu> sure, I've got some time :)
[17:07] <conscioususer> larsu: great! meanwhile I'll remember the 5 sec advice :)
[17:07] <conscioususer> larsu: I've been trying to use the command-line signal, but I'm missing something
[17:08] <conscioususer> http://www.pasteshare.co.uk/p/GA/
[17:08] <conscioususer> larsu: I need this to make Desktop Actions work on primary instances
[17:09] <conscioususer> larsu: this example I pasted *almost* works, but a secondary instance does not return after pinging the primary instance, it freezes
[17:09] <conscioususer> larsu: the ping does work, though, with the correct command line being sent
[17:09] <larsu> conscioususer, weird, let me try it otu
[17:09] <larsu> *out
[17:10] <conscioususer> larsu: I'm doing what the docs said, using the HANDLES_COMMAND_LINE flag and connecting to the command-line signal
[17:19] <conscioususer> larsu: so apparently there's nothing *obviously* wrong, right? :)
[17:19] <larsu> conscioususer, yeah, what you're doing looks right to me
[17:19] <larsu> I'm trying to find the issue right now ...
[17:21] <conscioususer> larsu: seems to big to be a gtk or pygobject bug too...
[17:21] <conscioususer> *too
[17:28] <larsu> conscioususer, yeah... some dbus method doesn't seem to be returning properly, which seems to keep the launcher instance awake
[17:28] <larsu> desrt, any idea what this could be ^^  ( http://www.pasteshare.co.uk/p/GA/ )
[17:30] <devnewbee> Hey there. sorry for interruption. where in the code do I find the invokation of the dashboard of the unityshell, when cliked  on the button? thanks.
[17:31] <bschaefer> devnewbee, BFBLauncherIcon.cpp:90
[17:32] <bschaefer> unity/launcher/BFBLauncherIcon.cpp
[17:34] <devnewbee> I assume your talking about the OnOverlayShown method?
[17:34] <bschaefer> no
[17:34] <bschaefer> ubus_manager_.SendMessage(UBUS_PLACE_ENTRY_ACTIVATE_REQUEST, g_variant_new("(sus)", "home.lens", dash::NOT_HANDLED, ""));
[17:34] <bschaefer> sends a ubus message to DashController
[17:34] <bschaefer> which then shows the dash
[17:34] <bschaefer> but the Activate function is what gets called when you click on the icon in the launcher
[17:38] <devnewbee> cool. so at this point the icon is already identified and the dash is actually called by "home.lens"?
[17:39] <bschaefer> well that home.lens is the lens that gets started ie the default. The message that gets sent/received by the DashController is UBUS_PLACE_ENTRY_ACTIVATE_REQUEST
[17:40] <fginther> mterry, just an update, the server handling the merger testing is down, so I'm mostly stuck. Hopefully it will be up again soon
[17:40] <mterry> fginther, OK
[17:41] <devnewbee> bschaefer: IC. thank you so far. far more clear now. is there a code documentation somewhere?
[17:42] <bschaefer> sadly no :(
[17:42] <devnewbee> ooooh.
[17:42] <bschaefer> at lease not that im aware of
[17:43] <larsu> conscioususer, looks like you found a bug in GApplication, the CommandLine dbus call doesn't return a value. I wonder why this didn't turn up earlier...
[17:43]  * larsu might be wrong, though
[17:43] <devnewbee> ok maybe you can give me just a little hint on what Id like to do.
[17:44] <conscioususer> larsu: I'll take this as a sign of how many people are actually using GtkApplication to its full power
[17:44] <bschaefer> possibly :)
[17:44] <larsu> conscioususer, yeah :(  Someone's gotta start....
[17:45] <devnewbee> When an icon is hovered, then it shall be checked whether there is a "group" and open tiny dashlike view with those.
[17:45] <conscioususer> larsu: so this would also happen if I wrote the example in C?
[17:45] <devnewbee> bschaefer: so what woudl I need to look at for this?
[17:45] <larsu> conscioususer, afaics, yes. I'm trying that right now
[17:45] <bschaefer> devnewbee, a grouping of icons in the launcher?
[17:45] <bschaefer> or the icon it self is a grouping
[17:46] <bschaefer> devnewbee, either way, you'll need to look into LaucherIcon.cpp under mouse_enter signals
[17:46] <bschaefer> mouse_move
[17:46] <MCR1> bschaefer: Hi :) Do you have time for a short test of a Expo fix (I could even provide a binary for it, so you would not need to compile...) ?
[17:46] <conscioususer> larsu: damn, I guess I'll have to do some ugly stuff to allow different actions from secondary instances
[17:47] <devnewbee> bschaefer: Im not sure what you meant by that difference. the icon just offers on click other launchericons(the actual apps for that group, e.g. system, editors or so)
[17:47] <bschaefer> MCR1, hello, what kind of fix? plus I can just merge to a branch and compile it as easily as well
[17:48] <bschaefer> devnewbee, on which click? activate icon is on left mouse click, and quicklist is on the right mouse click...
[17:48] <MCR1> bschaefer: Thanks :) - I fixed the broken Expo animations - here is the branch: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix875311-expo-fadeandzoom-and-vortex-animations-black-screen/+merge/132731
[17:48] <bschaefer> devnewbee, either way, LauncherIcon.cpp is what handles mouse events for the icons
[17:49] <devnewbee> bschaefer: well. a left click to open a quicklist with real icon sotospeak :)
[17:49] <bschaefer> devnewbee, though you might have to look at LauncherController as well because LaucherIcon only knows about individual icons
[17:49] <bschaefer> MCR1, ill take a look
[17:50] <conscioususer> larsu: I guess I'll have to register the application, check get_is_remote and activate an action if it's remote
[17:50] <conscioususer> larsu: and call run if it's not remote
[17:50] <MCR1> bschaefer: I am currently using the .compiz-1 directory to test Compiz plug-in fixes...
[17:50] <desrt> conscioususer: crikey
[17:50] <desrt> what the heck are you doing? :)
[17:51] <devnewbee> bschaefer: ok. Ill check that. a hint how to replicate a little horizontal board for those icons?
[17:51] <desrt> why are you trying to do HANDLES_COMMAND_LINE?
[17:51] <larsu> desrt, is gapplicationimpl-dbus.c:173 missing a g_dbus_method_invocation_return_value?
[17:51] <bschaefer> MCR1, hmm Ill try to look at that later, as im working on something that I would rather not have to deal with compiz atm haha :)
[17:51] <desrt> larsu: no.
[17:52] <desrt> the reply is sent when the GApplicationCommandLine instance is finalized
[17:52] <bschaefer> devnewbee, horizontal board?
[17:52] <MCR1> bschaefer: I just put the compiled binary from build/plugins/plugin-name compiz source dir to .compiz-1/plugins in ~ and run setsid unity to test :)
[17:52] <desrt> this allows the invoking instance to do things like waiting to exit until the document that was opened by that commandline to close
[17:52] <conscioususer> desrt: my app has a command line parameter that should be considered regardless if the app is already running or not
[17:52] <MCR1> bschaefer: But no stress...
[17:52] <desrt> *was closed
[17:52] <MCR1> bschaefer: ofc :)
[17:52] <larsu> desrt, makes sense, but then why does the pasted example not return from the launcher?
[17:52] <bschaefer> MCR1, yeah, but it takes time haha
[17:53] <desrt> larsu: perhaps python is not releasing the object?
[17:53]  * bschaefer needs coffee and to finish working on something else
[17:53] <devnewbee> bschaefer: well yes. the offerend appicons should be displayed on a board, like the launcherbar itself or the dashboard looks like.
[17:53] <desrt> tying the exiting of the remote to the lifecycle of the commandline object was a pretty lame thing for me to do...
[17:53] <desrt> it should have been an explicit call
[17:53] <devnewbee> bschaefer: a square with transparent background woudl do it.
[17:54] <bschaefer> devnewbee, weelll to do that you need to look into Nux
[17:54] <bschaefer> devnewbee, and Views
[17:54] <bschaefer> and how to generate a blur texture
[17:54] <conscioususer> desrt: should we ping pitti?
[17:54] <desrt> conscioususer: ideally you should break the commandline arguments out on the remote side
[17:54] <desrt> and send action invocations
[17:54] <bschaefer> digging around anything View, like DashView, HudView will have bits of that, along with OverlayRenderer
[17:55] <conscioususer> desrt: are actions called only on the primary instance?
[17:55] <desrt> yes
[17:55] <desrt> if you invoke an action from the remote instance it will land on the primary side
[17:55] <desrt> ditto activate()
[17:55] <desrt> and open()
[17:55] <conscioususer> desrt: oh. so that'll be easier than I thought
[17:55] <conscioususer> desrt: no get_is_remote needed
[17:56] <desrt> conscioususer: no.  definitely not.
[17:56] <desrt> this is a mistake that a lot of former libunique users make
[17:56] <larsu> desrt, you're right about python. It works fine from C. It's quite confusing, though
[17:56] <desrt> larsu: i think we need some explicit exit() API
[17:56] <larsu> conscioususer, so this is a pygi issue, but I guess you have a different solution for now
[17:56] <desrt> i'll make a bug about that
[17:57] <larsu> desrt, agreed, thanks
[17:57] <conscioususer> larsu: it seems to, yeah
[17:57] <conscioususer> *so
[17:57] <devnewbee> bschaefer:  thanks a  lot . I'll come back if necessary.
[17:57] <desrt> oh lookie here
[17:57] <bschaefer> devnewbee, np! and good luck!
[17:57] <desrt> https://bugzilla.gnome.org/show_bug.cgi?id=682331
[17:57] <devnewbee> bye
[17:57] <conscioususer> larsu: GtkApplication is not the boogeyman I thought it was after all
[17:58] <devnewbee> bschaefer: yea . bye.
[17:58] <larsu> conscioususer, yeah it's pretty cool once you get out of the libunique thinking :)
[17:58] <conscioususer> another bug to subscribe to...
[17:58]  * desrt feels like fixing this bug today
[17:59] <larsu> desrt, also: why is command-line called for apps that have HANDLES_COMMAND_LINE set but no arguments are given?
[17:59] <conscioususer> larsu: ok, once that gmenumodel thing is fixed, polly gtk3 will be again on the right track :)
[18:00] <desrt> larsu: because no arguments is just a special case of n arguments?
[18:00] <desrt> would be quite odd to imagine the opposite, i think
[18:01] <conscioususer> desrt, larsu: thanks a lot to you both, I can go on now and I learned a lot :)
[18:01] <larsu> conscioususer, I don't have time anymore to fix it today, I'll try to fix it tomorrow morning. Also the mnemonic thing, that's just a missing call to gtk_label_set_use_underline
[18:01] <larsu> desrt, usually you call activate when no args are given...
[18:02] <desrt> larsu: or open when args are given
[18:02] <larsu> yeah
[18:02] <desrt> commandline is the way of saying "i want to deal with this"
[18:02] <larsu> hm, okay
[18:02] <conscioususer> larsu: take your time :)
[18:03] <desrt> all of this magic is in the default implementation of local_command_line
[18:03] <desrt> you can override that and do whatever you want
[18:03] <desrt> HANDLES_COMMAND_LINE doesn't even have any meaning outside of that function
[18:03] <conscioususer> larsu: btw, if it's just such a harmless change, maybe it could qualify for a precise SRU?
[18:04] <larsu> conscioususer, I'm not on the release team, but we can certainly try. Note that this only really effects you as a developer: most users won't stop and restart polly in < 5 seconds
[18:04] <conscioususer> larsu: oh, I was referring to the mnemonic thing
[18:05] <conscioususer> larsu: the 5 seconds thing, I have no idea if the fix seems harmless or not :)
[18:05] <larsu> conscioususer, oh! Ya, that's a fix in gtk... that's much harder to get a SRU for
[18:05] <larsu> actually, I could do the fix in indicator-appmenu for now...
[18:11] <desrt> hmmmmmmm
[18:11] <desrt> this bug is difficult to fix
[18:13] <seb128> larsu, do you call me hard to work with there?!
[18:13] <larsu> seb128, never! :)
[18:13] <seb128> yeah yeah
[18:14] <seb128> but yeah, the less GTK uploads to do the happier I am ;-)
[18:14] <larsu> seb128, I know, I just didn't want to get conscioususer's hopes up before talking to you ;)
[18:16] <larsu> didrocks, argh, which one??? https://bugs.launchpad.net/ubuntu/+source/bamf/+bug/718926/comments/26
[18:16]  * larsu wonders if this is still an issue in bamf. the workaround in indicator-appmenu is buggy
[18:16] <mterry> mardy, poke about building unity-lens-gdocs.  I'm hitting an error like "xgettext: error while opening "../unity-scope-gdocs.application.in.h" for reading: No such file or directory"   Have you seen that before?
[18:17] <didrocks> larsu: it was fixed shortly after, hence the no reference to bug # IIRC
[18:17] <didrocks> larsu: but with every info old from 7 month, my memory can turn ugly ;)
[18:17] <larsu> didrocks, cool, thanks! (I'm fine with you not writing down bug numbers if you remember all of them ;) )
[18:19] <larsu> seb128, is a indicator-appmenu SRU for this kind of stuff okay?
[18:20] <seb128> larsu, is that a real world issue or just a "if close and run it again in the next 5 seconds"
[18:20] <larsu> seb128, it's even better: close it and run it again in the next 5 seconds *and* have X give it the same xid
[18:20] <larsu> (which happens more often than one might think)
[18:21] <larsu> but yeah, I admit it's quite an edge case
[18:21] <seb128> larsu, I wouldn't bother SRUing that alone in a nonLTS
[18:21] <seb128> larsu, it might be good to batch with some extra fixes when we get some
[18:22] <larsu> seb128, right
[18:29] <MCR1> Another fix: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix-1075578-workspacenames-flickering-during-display/+merge/133124