[07:50] <didrocks> sil2100: hey, https://code.launchpad.net/~3v1n0/bamf/libreoffice-base-and-tests-0.3/+merge/129005 is important IMHO (approved but not merged, i think you didn't add the quantal branches for those?)
[07:50] <didrocks> would be nice to confirm that it fixes "double clicking on an odt file in nautilus shows no appmenu"
[07:51] <sil2100> didrocks: let me look at it, but it indeed looks important
[07:51] <didrocks> sil2100: not sure the fix is related to that (I just had a quick look TBH)
[07:52] <sil2100> didrocks: will test-build it then, but I see the bug is already set for SRU0/1
[07:53] <didrocks> sil2100: thanks! do not forget to restart bamfdaemon and unity (or use a guest session) for testing :)
[07:53] <sil2100> didrocks: I tend to use the guest session, since I can't guarantee anything on my main one ;p
[07:53] <didrocks> heh ;)
[09:02] <sil2100> didrocks: tested the bamf branch - it doesn't fix the appmenu issue, since it's just related to LO Base, but it works
[09:04] <didrocks> sil2100: ok, thanks for testing, good to put it in the SRU0 world then :)
[09:09] <sil2100> didrocks: np ;)
[09:49] <Trevinho> didrocks: hey, what was the bug you're referring to?
[09:51] <sil2100> Trevinho: https://bugs.launchpad.net/bamf/+bug/1026426
[09:52] <sil2100> Trevinho: this probably...
[09:52] <Trevinho> sil2100: that's another bug, that's fixed by https://code.launchpad.net/~3v1n0/bamf/libbamf-safer-factory-rematch-2.0
[09:52] <Trevinho> sil2100: at that point, could you please approve the precise branches for https://code.launchpad.net/~3v1n0/bamf/libbamf-safer-factory-rematch-2.0 and https://code.launchpad.net/~3v1n0/bamf/libreoffice-base-and-tests-0.2 ?
[09:53] <sil2100> But that's for 0.2, right?
[09:53] <Trevinho> sil2100: yeah => precise
[09:53] <sil2100> Ah, I see a 0.3 too
[09:53] <sil2100> Awesome!
[09:54] <Trevinho> the 1026426 bug was alredy fixed in 0.3
[09:54] <sil2100> I'll test-run it
[09:54] <Trevinho> sil2100: it would be nice to have a P SRU then
[09:55] <sil2100> Indeed!
[10:33] <Mirv> yeah, that's what I asking as well
[10:34] <Mirv> and I targeted the 1026426 also to precise for that reason
[10:38] <MCR1> sil2100: Hi :) Something seems to be wrong with the Unity merger...
[10:38] <MCR1> https://code.launchpad.net/~unity-team/unity/trunk
[10:39] <MCR1> It mixed my merge request with bschaefer's commit somehow...
[10:39] <MCR1> didrocks ^^
[10:39] <MCR1> see r2827
[10:39] <MCR1> never seen this before
[10:41] <didrocks> MCR1: ask mmrazik|lunch and francis: they changed the merger, not really familiar how it works
[10:43] <MCR1> ok - seems strange though - I am now checking if my change was really merged
[10:45] <sil2100> Not good
[10:45] <MCR1> sil2100: You see the problem ?
[10:46] <sil2100> MCR1: was your branch approved by anyone for merging?
[10:46] <MCR1> sil2100: My merge request was marked as merged and mixed with bschaefer's commit, but my change has not been merged (just checked it)
[10:46] <MCR1> sil2100: Not 100% sure, but I think not as noone commented on it...
[10:47] <MCR1> sil2100: And it was NOT merged either
[10:48] <sil2100> This is really strange, LP says one thing, merge commit says something else
[10:48] <sil2100> mmrazik|lunch: ^
[10:48] <MCR1> yes exactly
[10:49] <MCR1> I am setting my branch up for review once again
[10:49] <sil2100> No, wait
[10:50] <sil2100> Let's wait for mmrazik|lunch to pop up back from lunch
[10:50] <MCR1> It fixes 3 bugs btw and should be approved by someone here :) - too late, sil2100 - I already did it
[10:50] <sil2100> Best if he sees the situation as it is
[10:50] <sil2100> MCR1: ah, no problem then
[10:50] <sil2100> MCR1: ;)
[10:50] <MCR1> ok
[10:51] <sil2100> MCR1: anyway, somethings broken - either LP is going mad or the new merger
[10:51] <MCR1> sil2100: The preview diff now shows no change although the change is not in trunk !
[10:51] <MCR1> sil2100: Something smells very fishy here
[11:07] <MCR1> sil2100: My branch was somehow !destroyed! during the process and I had to commit the change again - which is a small problem for a one line fix, but might be a big problem for more complicated branches...
[11:18] <sil2100> MCR1: ouch
[11:18] <sil2100> fginther, mmrazik|lunch: ^
[11:18] <sil2100> MCR1: I'll inform the guys about it
[11:18] <MCR1> thx
[11:19] <MCR1> not a big problem for me, but might be hard for others, so merges should be halted until fixed or there will be some angry programmers
[11:22] <sil2100> For me it looks like a rather critical issue
[11:22] <MCR1> yep, for me too
[11:23] <sil2100> As it essentially 'breaks' lp:unity a bit
[11:23] <MCR1> yes
[11:23] <MCR1> that is why I immediately reported it
[11:23] <sil2100> With attaching LP info to bugs that are not fixed, but marked as fixed etc. = not good
[11:23] <sil2100> MCR1: big thanks for noticing this
[11:23] <MCR1> to not f*ck up lp:unity completely
[11:24] <MCR1> Is the merger kjust new for Unity or also for Compiz and other projects ?
[11:24] <MCR1> *-k
[11:26] <sil2100> MCR1: from what I know all trunks are using the new merger, i.e. compiz, unity, nux, libunity, bamf etc.
[11:26] <sil2100> MCR1: the quantal branches are still using the old one
[11:26] <sil2100> (i.e. lp:unity/6.0)
[11:26] <MCR1> sil2100: Just FYI: The bugs did not get marked as fixed...
[11:27] <MCR1> smspillaz: Attention !!! ^^
[11:38] <mmrazik> MCR1: regarding the branch...
[11:39] <MCR1> mmrazik: Yes ?
[11:39] <mmrazik> MCR1: any chance brandon's branch included your revisions but didn't set your branch as prerequisite in the MP?
[11:39] <mmrazik> actually.. I can check myself
[11:40] <MCR1> mmrazik: No, as my change is not in trunk yet.
[11:40] <MCR1> mmrazik: But my branch was somehow changed in the process also, I had to re-commit my fix.
[11:41] <MCR1> mmrazik: as the diff was empty after the broken merge
[11:42] <mmrazik> MCR1: what does it mean "My merge request was marked as merged and mixed with bschaefer's commit"
[11:42] <mmrazik> I don't understand the "mixed" part
[11:47] <MCR1> mmrazik: https://code.launchpad.net/~unity-team/unity/trunk
[11:48] <mmrazik> MCR1: I see... thanks
[11:48] <MCR1> Look at the last commit (r2827) - it says Merged branch lp:~mc-return/unity/unity.merge-fix1006429-fix1006434-fix1063171
[11:48] <MCR1> but this is not true at all
[11:49] <mmrazik> MCR1: I'm just looking at the log of Brandon's branch
[11:49] <mmrazik> and there is a merge from your branch indeed
[11:50] <mmrazik> MCR1: its r2817 in his branch
[11:50] <mmrazik> sil2100: ^^^
[11:51] <mmrazik> MCR1, sil2100: TBH I don't know what we should do with stuff like this. It would most likely happen with the old merger as well as this part is still tarmac code
[11:51] <MCR1> mmrazik: Do you have a link ? Strange, because my change is not in unity trunk yet, see https://code.launchpad.net/~mc-return/unity/unity.merge-fix1006429-fix1006434-fix1063171/+merge/129150
[11:51] <mmrazik> MCR1: this is what I did. Not sure where to find it in launchpad:
[11:52] <mmrazik>  bzr branch lp:~brandontschaefer/unity/alt-grave-ordering-fix
[11:52] <sil2100> Confusing
[11:52] <mmrazik>  bzr log --include-merged|less
[11:53] <mmrazik> that explains why it closed the bugs... the branch was included in Brandon's... so bzrlib/tarmac did some magic and found all the branches in tarmac, marked them merged
[11:53] <mmrazik> it is just weird that the change didn't really make it into trunk
[11:54] <MCR1> I think Brandon tested my branch, maybe something got mixed there - but I am clueless
[11:55] <mmrazik> weird is that the merge is in his log but the change isn't
[11:55] <mmrazik> maybe he reverted it?
[11:55]  * mmrazik is looking into it a bit more
[11:55] <MCR1> might well be
[11:56] <MCR1> mmrazik: Sorry 4 the problems I am causing :-[
[11:56] <mmrazik> MCR1: not your fault ;)
[11:56] <mmrazik> don't worry
[11:58] <MCR1> I am happy that at least the unity code was not mixed up by this... - so it is just a wrong commit message we are dealing with here...
[11:59] <mmrazik> MCR1: well.. the commit message is sort of correct given that according to the log brandon's branch has some info about merging yours
[11:59] <mmrazik> the weird thing is that the diff for that revision seems to be unrelated
[11:59] <mmrazik> maybe he merged, then reverted (manually), did some more changes
[12:00] <mmrazik> and commited
[12:00] <MCR1> probably
[12:00] <mmrazik> let me followup by e-mail
[12:00] <mmrazik> but to me this looks pretty much like some bzr/launchpad misuse
[12:00] <mmrazik> from what I see in the logs/branches this behavior is expected when you do stuff like this
[12:01] <mmrazik> sil2100: FYI ^^^. I'll followup to your e-mail.
[12:02] <mmrazik> MCR1: what is your e-mail so I can CC you?
[12:02] <mmrazik> (feel free to private msg; I'm just too lazy to find out myself)
[12:37] <didrocks> 13:53:06   mmrazik | that explains why it closed the bugs... the branch was included in Brandon's... so bzrlib/tarmac did some magic and found all the branches in tarmac, marked them merged
[12:37] <didrocks> -> this is normally launchpad doing that automatically
[12:38] <mmrazik> ok... so not bzrlib but launchpad..
[12:38] <didrocks> when you push a branch it scans the new commits
[12:38] <didrocks> and check if all rev in every MR is included
[12:38] <didrocks> and close them
[12:38] <mmrazik> I think I tried that manually once and it didn't do it
[12:38] <mmrazik> so thats why I thought bzrlib/tarmac is doing something more
[12:38] <mmrazik> but I might be just mixing stuff
[12:38] <didrocks> mmrazik: maybe there are some hiccups, but by using that at least 10 times a day, I can ensure you it generally works :)
[12:39] <mmrazik> didrocks: it actually makes more sense
[12:39] <mmrazik> good to know
[12:45] <Mirv> could someone with nvidia binary, someone with nvidia nouveau and/or someone with fglrx try out the nux from  ppa:timo-jyrinki/prerelease in quantal and report back if seeing anything regressing in bringing Dash visible / active blur?
[12:46] <Mirv> there's a performance patch included that probably shouldn't cause any trouble, but since I'm currently only able to test on intel...
[12:58] <mhr3> Mirv, tested nux trunk with nouveau, works fine, don't see any regressions
[12:58] <Mirv> mhr3: thanks
[12:58] <Mirv> yeah, nux trunk is fine as well for testing :)
[12:59] <mhr3> (otoh i don't see any performance benefits either)
[12:59] <mhr3> guess it's something small
[12:59] <Mirv> it's small withing the context where dash causes all the slowness by drawing its contents over and over again
[13:00] <Mirv> still it should help in some cases
[13:26] <groverblue> I just read that Unity will do away with 2D.  I think this is a problem because (form my usage experience), 3D does not work well when I remote desktop into my Ubuntu machine.  The screen does not redraw properly.
[13:30] <Mirv> groverblue: the current solution is software rendering via llvmpipe
[13:30] <Mirv> but there will be surely more work done on that front as well. fortunately 12.04 LTS will be supported for 5 years with its unity-2d.
[13:32] <groverblue> good to hear on the support.  I just wanted to make you guys aware that 3D + desktop sharing is an issue.
[13:32] <groverblue> thank you for your response.
[15:25] <didrocks> sil2100: did you try https://bugs.launchpad.net/bamf/+bug/1026426?
[15:27] <sil2100> didrocks: no, but I see Timo checked it and approved it
[15:27] <sil2100> didrocks: although now I notice there's only a merge to trunk and 0.2
[15:27] <sil2100> 0.3 is missing
[15:28] <didrocks> does it fix the "double click on a file and getting the appmenu?"
[15:28] <didrocks> Trevinho: ^
[15:28] <sil2100> Trevinho: could you backport it to 0.3 ?
[15:34] <Trevinho> sil2100: it's already in 0.3...
[15:34] <Trevinho> sil2100: (rev 487)
[15:34] <sil2100> Oh, didn't see it linked in the bug
[15:35] <Trevinho> didrocks: mhmh.. not sure I got the issue... double clicking in an LO file... and?
[15:35] <didrocks> Trevinho: you have a match in the launcher
[15:35] <didrocks> Trevinho: but no appmenu
[15:35] <Trevinho> didrocks: ah... well, I've never noticed it
[15:36] <Trevinho> didrocks: chcking now, but it should be the same
[15:36] <didrocks> Trevinho: can you have a look, just to ensure bamf isn't guilty?
[15:36] <didrocks> that there is no nasty race :)
[15:36] <Trevinho> didrocks: no, it doesn't fix it
[15:36] <Trevinho> didrocks: need to switch back to another win to see the menus
[15:37] <didrocks> Trevinho: ok, you think it's rather on libreoffice side than bamf?
[15:37] <didrocks> yeah, exactly
[15:38] <Trevinho> didrocks: well... let me think... need to check the panel code side
[15:38] <didrocks> thanks Trevinho ;)
[15:38] <didrocks> sil2100: FYI ^ (as I pinged you to track it yesterday ;))
[15:38] <Trevinho> didrocks: do we have a bug for that as well?
[15:39] <didrocks> yep, one sec
[15:40] <didrocks> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1064962
[15:41] <Trevinho> now didrocks funny thing... if I do a gdbus monitor --session --dest com.canonical.Unity.Panel.Service --object-path /com/canonical/Unity/Panel/Service then the bug disappears
[15:41] <Trevinho> mh, ok, not anymore
[15:42] <didrocks> Trevinho: really funny :)
[15:42] <Trevinho> and now again... -_-
[15:48] <Trevinho> didrocks: it doesn't seem an unity issue tough... Since also the panel service has not any menu stored... also doing a Sync after some time that LO has been opened, still the panel service has no menus...
[15:48] <Mirv> sil2100: I branched 0.3 from trunk only after the merge
[15:48] <Trevinho> so it seems more an indicator-appmenu issue
[15:48] <didrocks> Trevinho: ok, thanks for confirming, can you ping Sweetshark on #ubuntu-desktop with that info?
[15:49] <didrocks> and ted
[15:49] <Trevinho> didrocks: yes
[15:49] <didrocks> thanks Trevinho ;)
[15:49] <sil2100> Mirv: ah ;)
[15:49] <sil2100> Mirv: ok, thanks
[15:50] <sil2100> didrocks: I tried pinging ted twice, but e-mail is best probably
[15:50] <didrocks> sil2100: maybe try on #systems?
[15:50] <didrocks> larsu and others can have a look
[17:37] <ViaNocturna> wonder if anyone can help, when i log in, unity has no transparency etc, it takes a few log outs and log ins to get the full unity3d, anyone have any ideas why?
[20:57] <LBo> Hi, I'm using appindicator3 for a timer application
[20:57] <LBo> It display %H:%M in the indicator label
[20:58] <LBo> And I would like the colon to blink
[20:58] <LBo> Replacing it with a space every second doesn't work because of the font spacing
[20:59] <LBo> Is there a way I can achieve this?
[21:01] <seb128> LBo, that doesn't seem like a good idea
[21:02] <seb128> LBo, I don't know about the spacing question but that will create constant activity on the bus and wakeups for the system preventing any power manager to do its job
[21:03] <LBo> seb128: ok, good argument
[21:03] <meebey> seb128: are you involved in libmessaging-menu btw?
[21:03] <meebey> seb128: I ported Smuxi to it and noticed an odd side effect
[21:03] <seb128> meebey, "involved", I used it and I'm following what those guys do but I'm not involved in the code
[21:03] <LBo> I'll keep it to minute feedback then
[21:04] <meebey> seb128: ic, do you know if its by design that the application entry in the msg menu will always start (invoke) the application?
[21:05] <meebey> that works great as long as the application support single-instance, when not its a real pain though
[21:05] <seb128> LBo, great ;-)
[21:05] <LBo> seb128: thanks for the help
[21:05] <meebey> seb128: when you activate it I mean
[21:05] <seb128> meebey, I mentioned it to Lars when I ported xchat-indicator
[21:05] <seb128> LBo, yw!
[21:06] <meebey> there is a source-activated event, too bad that wasnt used for the app itself...
[21:06] <meebey> could have been null as source_id or so...
[21:06] <seb128> meebey, it's not so much "by design" that the recommended app behaviour, he wasn't against adressing that usecase, it just didn't think about it for the first iteration
[21:06] <meebey> seb128: what was the outcome, or are there known workarounds?
[21:06] <seb128> it->he
[21:06] <meebey> seb128: ic
[21:07] <meebey> seb128: Lars is the main dev of it?
[21:07] <seb128> the outcome was "yeah; we should probably do something about that"
[21:07] <seb128> yes
[21:07] <meebey> I should maybe talk to him then
[21:07] <seb128> he's larsu on IRC
[21:07] <meebey> thank you
[21:07] <seb128> he's online during european work hours
[21:07] <seb128> yw
[21:07] <seb128> just open a bug otherwise
[21:07] <seb128> he reads those
[21:07] <meebey> will do
[21:07] <seb128> it would be good to have that registered in the tracker in any case
[21:07] <seb128> great
[21:08] <meebey> ack
[21:11] <meebey> seb128: last question, what is the right project on LP? searching for libmessaging-menu wasnt that useful
[21:11] <meebey> only found branches by ken
[21:11] <seb128> meebey, indicator-messages
[21:12] <meebey> yeah, https://bugs.launchpad.net/indicator-messages thanks
[21:17] <meebey> https://bugs.launchpad.net/indicator-messages/+bug/1065732
[21:30] <davidcalle> popey, I've just pushed a new commit on the merge. Another call wasn't stopped. SRU 0 material I suppoe.
[21:31] <davidcalle> suppose*
[21:32] <popey> davidcalle, thank you, yes, that's the plan
[21:33] <davidcalle> popey, by the way, do you have a screenshot of the new legal button in the lens bar? I'm pretty curious about how it's going to be presented.
[21:33] <popey> not yet, no
[21:36] <seb128> davidcalle, the version it is in the ubuntu-desktop ppa if you want to try it
[21:36] <seb128> davidcalle, it's basically a label in the lens bar at the right
[21:37] <seb128> davidcalle, it looks ok
[21:37] <davidcalle> seb128, thanks!
[21:37] <seb128> yw