#ubuntu-unity 2012-07-01 <mpereira_> i wrote a very simple indicator, compiled and ran it but it doesn't show up on the menu bar. i may be doing something stupid; can anyone point me to the right direction? https://gist.github.com/3026227 <david___> quick question... whats a good unity resource? I know I can Google it, I am ust looking for recommendations, Thanks. <popey> david___, resource for what? <david___> I do alot with mono and I would like to integrate with it better but I only really see the C and python api's <david___> I guess I would like to know if there is something for mono or just more generic that I can work with <popey> hmm, not sure, probably best to drop by here during the UK/US daytime during the week really.. <popey> its pretty quiet during the weekends <david___> thats cool. I will do that. thanks <popey> np <mpereira_> i wrote a very simple indicator, compiled and ran it but it doesn't show up on the menu bar. i may be doing something stupid; can anyone point me to the right direction? https://gist.github.com/3026227 <mhr3> Trevinho, ping? #ubuntu-unity 2012-07-02 <didrocks> sil2100: hey <didrocks> sil2100: what's the status about unity/dee/the stack release for quantal? <sil2100> didrocks: we were testing the nux + unity + lens, ETA for the stack is for tomorrow <thumper> didrocks: should the unity devs be based on quantal now? <didrocks> sil2100: ok, I think your coordinated this with upstream, right? and have a versionning with bugs that are closed/new features :) <thumper> or is it still ok to be precise? <didrocks> thumper: I guess they should, some code was committed in compiz not compatible with the newer boost for instance <didrocks> thumper: quantal is quite stable, didn't get any "no X, no sound" issue <thumper> didrocks: orly? like what? <didrocks> thumper: I can find it back if needed, but can't happen anymore now. I added automerging to compiz <thumper> \o/ <thumper> not entirely necessary <thumper> I was just curious <sil2100> didrocks: I hope I do... <sil2100> didrocks: for dee, will we be releasing a new tarball? Or should we stick with the old one? Since I don't see too much changes being made besides the overrides thing... <didrocks> sil2100: well, I want the overrides thing, then, check with upstream about the better plan for them :) <sil2100> ACK <sil2100> mhr3: could you comment on that ^ ^ <mhr3> let me check the changes <sil2100> mhr3: I just see the overrides thing and one debugging thing <sil2100> mhr3: nothing more <mhr3> sil2100, right, so you're basically going to sru current trunk :) <sil2100> mhr3: not only SRU - also a quantal release <sil2100> mhr3: so, we can stick with the current tarball? <mhr3> sil2100, up to you really, if you say you want new tarball i'll make it <sil2100> didrocks: in the case of not doing a new tarball release, should I also cherry-pick the 'post release bump' commits from trunk? i.e. the commit that changes the configure.ac version number to a development version (in this case, 1.0.11)? <didrocks> sil2100: if you are not doing a new tarball, please don't cherry-pick the bump <sil2100> didrocks: ok <didrocks> this is confusing then that the package version doesn't match the library one <sil2100> mhr3: if you don't mind, I'd stick with the current tarball for now - since there's not too many changes made, so I personally would think it would be a bit pointless <sil2100> mhr3: so I'll just cherry-pick those <mhr3> sil2100, as you wish <sil2100> mhr3: btw. is the whole dee trunk SRUable? Or are there any commits on there that I should not cherry-pick? <mhr3> sil2100, you can take everything <mhr3> minus the bump as didrocks said <sil2100> mhr3: excellent, thanks! <mhr3> sil2100, are you rebuilding lenses with latest vala in quantal? <sil2100> mhr3: I think I will have to I guess - is there some work involved with it? <mhr3> they'll probably start crashing <sil2100> mhr3: and what about dee? Does anything need to be done for everything to work with the new vala? Or should I stick with the old one? <mhr3> not right away, we just saw music lens does after activating an album <mhr3> dee doesn't care about vala <sil2100> Good <sil2100> hm <sil2100> didrocks: can we stick with the old vala with the lens for now? <sil2100> Since I see you started the switch for libunity already <didrocks> mhr3: ah! see it's not stable <didrocks> seb128: FYI, you were telling the new vala world was great^ <didrocks> mhr3: can we keep libunity with the new vala? <didrocks> as it's fixing the gir bug <didrocks> mhr3: sil2100: unity-lens-music is building with vala 0.14 <mhr3> didrocks, i thought you moved everything to 0.18 for Q? <didrocks> mhr3: not everything :) <mhr3> didrocks, so what was moved? <mhr3> just libunity? <didrocks> mhr3: yep <didrocks> mhr3: the crash happens with the package? <mhr3> didrocks, it's ulm-specific <didrocks> doesn't tell me if it's with the package :p <mhr3> didrocks, but i can't really tell if the switch in libunity will introduce more crashes <mhr3> i didn't see anything too bad here, but i've been just running some tests, not real system <didrocks> mhr3: but this ulm crash, it's not the package right? <didrocks> just if you build locally with latest vala? <mhr3> didrocks, no, it'll happen if you rebuild current src wih 0.18 <didrocks> ok, you got me scared ;) <didrocks> mhr3: let's see and try libunity with vala 0.18 <didrocks> and keeping the rest/upgrading to 0.16 <didrocks> sil2100: ^ <pstolowski> mhr3, didrocks missed beginning of your discussion, but the sooner we switch the better, even if it crashes a lot... <mhr3> didrocks, agreed, that's the only way to see what happens :) <didrocks> pstolowski: no <didrocks> pstolowski: we won't push into ubuntu versions that crashes <sil2100> didrocks: ACK <sil2100> So 0.18 for libunity, rest - the old one? <mhr3> didrocks, oh, wait, 0.16 will crash as well <mhr3> only 14 is safe for lenses atm <didrocks> sil2100: yeah, apart if when you do the package upgrade, you see a lot of crashes <didrocks> mhr3: ok, so keeping 0.14 for lenses <didrocks> which is what they are on <mhr3> fine <didrocks> sil2100: so, basically, you have nothing to do :) <mhr3> there's still the icon path 5 -> 6 <didrocks> sil2100: just ensure if you do a local build (not in pbuilder), that you selected the right update-alternatives valac version first <sil2100> One moment, meeting <sil2100> mhr3: I fixed that locally, so I'll just re-do and push <sil2100> didrocks: when I'm done, I'd like to confirm some things ;) <sil2100> (done with the meeting) <seb128> didrocks, re, I was at lunch ... what's up with vala? ;-) please use 0.16 or 0.18 if you can <didrocks> seb128: we can't <didrocks> crashes with both <didrocks> for lenses <didrocks> that's just the ping was about :) <seb128> oh <seb128> didrocks, that's likely a bug in mhr3's code! <didrocks> seb128: agreeing ;) <mhr3> seb128, didrocks but it's because they keep changing vala behaviour :P * didrocks heard one week before that "vala was really stable now, nothing to fear, blablabla" from 2 people here ;) <seb128> lol <mhr3> didrocks, you got me now :P <didrocks> \o/ <sil2100> Ok everyone, I would like to release a new unity stack for quantal around tomorrow - any objections to that? <gord> mhr3: think we should wait till after release before merging in the preview api branch to unity core? ^^? <mhr3> gord, well, it's just api, and not hooked up, so it could go in imo <sil2100> It won't break anything? <sil2100> Since I'd like to ask for a trunk freeze for tomorrow <gord> shouldn't do <mhr3> anyhow, someone will have to approve the branch first :) <gord> needs to wait for QA to re-review, yell at thomi tonight and maybe it'll get merged in before the morning <sil2100> Well, I do hope that tomorrow we'll have a freeze, since otherwise packaging work is a bit pointless <mhr3> i think qa is broken atm, cause i pushed and it didn't re-complain <gord> i mean thomi did a review already and wanted some changes right? <gord> not the qa lab stuff <gord> the qa lab stuff is just dice rolling <mhr3> ah, no, marco was looking at it <mhr3> Trevinho, so feel free to re-review now ;) <gord> hum, you are right. whos review am i thinking of.. <Klap-in> seb128: i have a question about a bug fix, is there a chance that it can be included in the precise? https://bugs.launchpad.net/ubuntu/+source/compiz-plugins-main/+bug/904205 <ubot5> Ubuntu bug 904205 in Compiz "Desktop wall: Bindings for next/previous don't wrap to the next row" [Wishlist,In progress] <seb128> Klap-in, hey, yes it seems to be fine for a SRU <seb128> Klap-in, but it needs to be reviewed,commit first <sil2100> Klap-in: could you submit a merge request? Probably best for both compiz trunk and compiz-plugins-main <Klap-in> sil2100: ok, i did a merge request on the compiz-plugins-main <Klap-in> on the default, thus on the devel branch. <sil2100> Klap-in: ah, see it now, thanks <sil2100> Klap-in: we'll try having that reviewed <Klap-in> is a extra mergerequest on compiz usefull? <sil2100> Klap-in: well, it's good to have the same fix applied on both trunk and precise - if the bug appears on both, which is the case here <sil2100> lp:compiz now has all the plugins merged into its source tree, so it's essentially just cherry-picking it into the new tree and testing if it works on trunk <Klap-in> sil2100: ok, then i do also a merge request on compiz <Trevinho> mhr3: you was referring to the ap fix branch? or to the previews one? <mhr3> Trevinho, the latter <Trevinho> mhr3: ok, looking at the introspection bamf... <Trevinho> mhr3: I guess we had a bug about it to link... <mhr3> Trevinho, hmm, i'm still wondering if there should be two girs (one for gtk2) <Trevinho> mhr3: probably yes... <mhr3> do we care about gtk2? :P <mhr3> it's not like introspection worked too much there :) <Trevinho> mhr3: I mostly did on the code... there was some projects depending on libbamf (not 3 version) <Trevinho> mhr3: bamf_matcher_get_xids_for_application returns a GArray that should be free'd... (even if now it's not implemented, I've implemented in the gdbus branch [that it's done, but I'm always forgetting to request for merge...]) <mhr3> Trevinho, that's why the annotations are in the .c files, so they can be easily updated when the method changes <sil2100> didrocks: regarding music lens - do you want to release a new tarball with that one commit you got merged in, or can I do it as a patch? <didrocks> sil2100: would be nice to do a release for this one I guess <sil2100> didrocks: a new tarball, yes? <sil2100> ACK <Trevinho> mhr3: bamf_matcher_get_active_window could return null (if not connected to the daemon or other odd cases) <sil2100> didrocks: so maybe we'll SRU it as well? <didrocks> sil2100: hum, no <didrocks> sil2100: how do you want to SRU that? <didrocks> it's a new feature :) <sil2100> didrocks: ok - just saw bugs linked to it like 'unknown albums might bla bla' so I thought it's a bugfix too <didrocks> sil2100: it is, but it adds translations <didrocks> sil2100: as if you looked at merge request content would have tell you ;) <didrocks> sil2100: you really need to start looking at those! <sil2100> didrocks: I know I know! But asking first never hurts! ;) <sil2100> Besides, I have yet to master vala <sil2100> As my vala-foo is weak <didrocks> sil2100: well, you really don't want to :p reading is easy, writing is less IMHO :p <sil2100> didrocks: since we will be switching to 6.0 with this release, should I switch the paths from 5 to 6 in the new tarball already? <sil2100> For the assets <sil2100> Or should I leave it as 5 and just do a patch with switching to 6? <mhr3> Trevinho, actually i didn't use that properly, gir specifies nullable only for method parameters <sil2100> hm, crap, I'll have to submit merge requests to all the lenses :| <mhr3> Trevinho, pushed fix <didrocks> sil2100: don't move it if it's not necessary to move it <Trevinho> mhr3: oh, yes... so we can avoid to specify that <sil2100> didrocks: so a patch? <Trevinho> implementers should always perform null checking... <didrocks> sil2100: if upstream moved it, move them <didrocks> if not, don't :) <sil2100> didrocks: well, when releasing unity 6.0, we'll have to switch from 5 to 6 or the icons will be not visible - upstream lenses didn't move yet because unity 6.0 is not released yet <sil2100> But it will have to sooner or later <sil2100> Anyway, I'll release the tarball in the state the trunk is now <didrocks> sil2100: good :) <sil2100> And then just proceed normally ;) <mhr3> didrocks, you evil little you, don't discourage sil2100 from writing patches for us :P <sil2100> mhr3: ;) <sil2100> mhr3: you want to roll-out the new tarball, or should I do it? <sil2100> mhr3: for the music lens? <mhr3> you want a tarball? <mhr3> did we actually have changes? <didrocks> mhr3: I am that evil! <didrocks> mhr3: you have awesome changes <didrocks> in the music lens <mhr3> didrocks, of course we do :) <mhr3> sorry didn't notice your stuff got merged already <didrocks> mhr3: I see how deeply sorry you are, that's fine :-) <mhr3> omg! <mhr3> a see a tab in the diff <mhr3> how could you?! <sil2100> !!! <gord> BURN THE TABBER <sil2100> RED, cannot release! Tab in the diff! <Trevinho> mhr3: in lp:~mhr3/unity/update-core-preview-api what about using st33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abunique_ptr for pimpl? (just to be more C++11 :)) <mhr3> Trevinho, can't, it doesn't compile <Trevinho> mhr3: yes, you just need to keep an empty destructor <Trevinho> mhr3: keep the ~Class(() {}... and it will work <mhr3> Trevinho, for the Impl? <mhr3> Trevinho, or the Preview subclasses? <Trevinho> mhr3: no, for the wrapper class <mhr3> sil2100, so i suppose that would be ulm 6.0? <sil2100> mhr3: hm, not sure <sil2100> mhr3: ...probably? <mhr3> sil2100, and should i bump the icon path in the .lens file as well? <sil2100> mhr3: well, the icon path - I originally wanted to wait with that till unity 6.0 gets released - but if the tarball will have version 6.0, I think this would make the most sense <sil2100> mhr3: so I think yes <mhr3> crap <mhr3> i almost tagged bamf instead of ulm <mhr3> sil2100, anyway tarball up <sil2100> mhr3: \o/ Thanks! <mhr3> sil2100, btw when producing tarballs i push straight to trunk without the mergers, that's how we used to do it with didrocks <mhr3> not sure what/if that changes anything for you <sil2100> mhr3: not really, it's ok for me too <mhr3> Trevinho, pushed unique_ptrs <Trevinho> mhr3: good ;) <mhr3> and i continue to think c++ is stupid :) <mhr3> i would expect it to have proper error messages after being developed for 20+ years <mhr3> but i suppose they're too busy having to implement glr parser :P <sil2100> didrocks: new tarball imported (new upstream release) in packaging for ulm: lp:~sil2100/unity-lens-music/quantal_PRE <didrocks> sil2100: please, prepare everything and I will review when everything is ready <didrocks> and that you have tested and so <sil2100> didrocks: ACK <sil2100> Well, I have almost everything else prepared too, just waiting for the possible trunk freeze tomorrow for unity and nux <sil2100> So that I won't have to re-do all the work <sil2100> mhr3: regarding libunity - you want to release a new tarball, or you think it's too early? <mhr3> sil2100, we released 5.90 already <mhr3> although i should do a new one <mhr3> sil2100, give me a moment <sil2100> mhr3: with this one we're switching to the new vala, so maybe a new release would be good <sil2100> Actually, hmm <mhr3> hmm at very least make check passes with latest valac :) <mhr3> didrocks, weren't you going to patch libunity to ship the gir or something? <didrocks> mhr3: we did it <didrocks> but wanted to remove it <didrocks> as the latest valac fixed it <didrocks> (so removed in the package) <mhr3> didrocks, but wasn't the gir missing for -dev? <mhr3> s/for/from/ ? <didrocks> mhr3: it's in now <mhr3> but it should be there anyway, no? <sil2100> Ok, so no new tarball for libunity? <mhr3> sil2100, it's on the way <didrocks> we ship 5.12.0-0ubuntu2 in quantal <didrocks> with the gir fix <mhr3> didrocks, ok nevermind, i thought we're forgetting to install it, but that doesn't seem to be the case... i guess i misunderstood you <didrocks> 5.90 was something I wanted that we do during the sprint <didrocks> mhr3: no, you did understand me very well, but in this case, it was more "blame the packager", but shhhh :) <mhr3> heh ok :) <sil2100> ...me? ;) <didrocks> no, was me :p <mhr3> sil2100, released <mhr3> sil2100, btw i'm evil and doing post-release bumps, you shouldn't push those to distro ;) <mterry> Heyo folks. Just wanted to raise bug 1020115 to attention. It affects the latest update-manager <ubot5> Launchpad bug 1020115 in unity (Ubuntu) "Spawned commands can't use pkexec" [Undecided,New] https://launchpad.net/bugs/1020115 <seb128> seems like a mhr3's bog! ;-) <mhr3> seb128, you knew something about that though, didn't you? ;) <seb128> mhr3, me? no, you must confuse me with somebody else <seb128> ;-) <mhr3> seb128, your jedi tricks won't work on me :P <seb128> :-( <seb128> mhr3, that would likely be a bug in the app lens right? <sil2100> Holy shit, bzr merge-upstream just crashed <mterry> seb128, it happens even from indicators <seb128> mterry, glib doing? g_spawn_...? <mhr3> seb128, well... we just use glib, so... <mterry> seb128, I wouldn't think it would set ppid to 1 automatically <mhr3> seb128, strangely synaptic uses it, but it's executed from a wrapper script <mhr3> (and works) <seb128> mhr3, mdeslaur added it to synaptic with that comment <seb128> "- debian/rules, debian/synaptic-pkexec: install wrapper to work around <seb128> .desktop files not being able to call pkexec directly." <sil2100> Did anyone get an error like this before in bzr merge-upstream? <mhr3> doesn't really tell why :/ <sil2100> NoSuchRevision: CHKInventoryRepository('file:///home/sil2100/Work/canonical/release/libunity/tmpVbvIP4/upstream/.bzr/repository/') has no revision djennings@example.org <mhr3> sounds like it's missing something <sil2100> Ah, one moment <didrocks> sil2100: never got that, did you -r -1? <seb128> sil2100, try asking #bzr? <didrocks> or -r -2 <sil2100> Yes, but uno moment <sil2100> o <didrocks> with the post release bump :) <mterry> mhr3, specifically, ppid is 1. I don't know why unity is causing that, but that's the root cause of the pkexec problem <mhr3> mterry, oh <mhr3> mterry, glib reaps the child processes by default <seb128> mterry, is that specific to unity or any g_spawn wrapper will do that? you said indicators have the same issue <sil2100> didrocks: probably the problem is in the fact that in the distro branch, there's an unreleased version present <mterry> mhr3, ah, so the g_spawn* family does set ppid to 1 automatically <mhr3> and when launching a desktop, there isn't really a way to *not* do that <sil2100> Aaaa <sil2100> No, waaait <sil2100> My mistake it seems! <didrocks> sil2100: no, it's not the problem <sil2100> grrr <didrocks> ah ok :) <didrocks> sil2100: it seems that you are releasing before testing right? <mterry> mhr3, seb128: OK, so you think it's not a unity problem. Do you think pkexec is being too strict, or should execl just be forbidden in this situation? <didrocks> sil2100: meaning that potentially the tarballs are not working fully/tested? <didrocks> so low quality? <didrocks> never trust mhr3's tarballs :) <mhr3> my tarballs have a "it's a trap" sticker <sil2100> didrocks: I'm not releasing anything, I'm preparing everything for testing <sil2100> didrocks: I prepare my distro branches so that I can build clean test packages from those <didrocks> sil2100: well, mhr3 did the release and published the tarball, right? <sil2100> And if it's green, I then just push it to the ether <mhr3> mterry, can't say really, maybe :) <didrocks> in case the tarball is not good, you would redo all the import? <mhr3> mterry, ie perhaps it has a reason :) <sil2100> didrocks: I would just do it all over again - but since it's only stored locally on my machine, it's not a big deal <sil2100> didrocks: and if it's not broken, I don't have to do anything but just pushing ;) <mhr3> mterry, but as can be seen with synaptic, a simple wrapper script workarounds the issue <seb128> mterry, I'm not sure to understand enough of the rational to comment on that, the comment seems to indicate that's to avoid running the command if the processus exited <seb128> mterry, would be good to check with mdeslaur or pitti <didrocks> seb128: as long as the tarball is not published into the Internet and no confusion is around :) <seb128> sil2100, ^ <seb128> sil2100, didrocks has tab completion issues ;-) <sil2100> It happens to me as well! <didrocks> grrrr ;) <didrocks> seb128: stop speaking! <didrocks> s<tab> complete the latest one :) <sil2100> didrocks: btw. the bzr merge-upstream problem I had - it seems to be caused by the previously unreleased version <sil2100> Since when I removed it, it worked fine <didrocks> ok <sil2100> Do I need something specific to make it work, or should I just remove the unreleased one and add it as the new one? <mhr3> didrocks, that's what you get for asking me to do tarball and then not releasing it! :P * sil2100 is confused with all the maddness going on here! <sil2100> You guys are crazy! <sil2100> ;p <mhr3> sil2100, don't worry, it's infectious <sil2100> :'( <mhr3> you'll be assimilated <mhr3> anyway, eod.. cyas <didrocks> mhr3: well, blame the sprint :) <sil2100> Ok guys, I'm finishing for today as well, time to let the PC cool off from all this afternoon heat-maddness <sil2100> See you tomorrow! <didrocks> see you sil2100 <MCR1> Do developers here have any comment on this: http://www.ubuntuvibes.com/2012/07/unity-revamped-adds-always-visible.html ? <Trevinho> MCR1: you should probably ask designers... <thumper> morning <MCR1> Trevinho: Where can I find the designers ? ;) <MCR1> Is someone here responsible for maintaining the Unity/staging PPA Quantal ? <MCR1> Unity in the PPA still depends on compiz-core-abiversion-20120305 and libgnome-desktop-3-2, so it is not installable :( <MCR1> I wonder how it passed the unit-tests :-/ <Trevinho> MCR1: you can ask on unity-design ML, or to JohnLea <seb128> not sure about the daily ppa but the packagers are after their end of work day <popey> they're all tucked up in bed getting their beauty sleep <popey> (or should be) <MCR1> Trevinho, seb128 thx 4 the infos. #ubuntu-unity 2012-07-03 <justjinxed> so is 1.4 million votes enough for developers to decide to allow users to move the unity bar? ;) <thumper> justjinxed: where are these theoretical 1.4 million votes? <thumper> justjinxed: however it is more complicated than that <thumper> it isn't the developers blocking it, but the designers <justjinxed> My question is more an IF than IS. Id like to know how to contact the responsible parties. I've read a number of varying opinions from the "team" but it's hard to pinpoint if any of them are an authority or not. <justjinxed> and now I must run for now, :( guess ill come back tomorrow and finish hunting them down :) <sil2100> Trevinho: give me a sign when you're around <popey> sil2100, he'll be around from ~14UTC <sil2100> grrr <sil2100> Thanks <smspillaz> anyone on this channel with an intel chip willing to test something quickly for me ? <smspillaz> intel graphics hardware <didrocks> sil2100: hey, I hope you are looking at the merge request and what I'm currently doing as soon, it will be your turn to do it :) <didrocks> popey: FYI ^ <sil2100> didrocks: which MRQ? <didrocks> sil2100: all of them, and the packaging update I'm doing, what is failing and such <sil2100> didrocks: since I'm looking at the Ibus one right now <didrocks> sil2100: I mean, you need to monitor all merge request, look at when/why they are failingâ¦ <sil2100> didrocks: ok, looking at those as well, but I have to deal with some unity-lens thing right now <didrocks> sil2100: indeed, but that shouldn't prevent monitoring merge requests :) <didrocks> juts a kind reminder, I won't remind you anymore of this then ;) <sil2100> didrocks: but please do, since otherwise I won't know that I screwed up again ;) And we don't want that happening too frequently! <didrocks> sil2100: well, I will reject the upload then, so you will learn that way ;) <sil2100> ;) <Mirv> smspillaz: o/ , although a meeting soon <smspillaz> Mirv: thanks, though I found a volunteer <Mirv> smspillaz: ok, great <sil2100> seb128: hi! <seb128> sil2100, hey, how are you? <sil2100> seb128: fine, although it's really hot here in Poland, how about you? <sil2100> The heat is killing me <seb128> sil2100, I'm good, weather is just nice here (around 23Â°C) <sil2100> seb128: remember the SRU for unity-lens-video that we made last week? <seb128> sil2100, yes, it got accepted yesterday <seb128> is there an issue with it? <sil2100> seb128: no, no issue, but David found another fix <seb128> sil2100, for what issue? <sil2100> I mean, the busy dbus issue that was seemingly fixed with this version - he found one more place where the bug might happen and fixed it yesterday as well <sil2100> So it would be nice if we could release, ekhm, another SRU with the one more fix... <sil2100> ...would that be possible? <davidcalle> seb128, dbus crash, there is a second dbus call in the code (for zeitgeist). I missed it last week. <davidcalle> seb128, sorry about that. <seb128> davidcalle, no worry <seb128> sil2100, yes, just do an update on top of the previous one <sil2100> seb128: is there a specific branch I should use? Or you don't care about bzr history? <seb128> sil2100, don't care about the history for the SRU <seb128> sil2100, but you can use the vcs for the quantal upload <sil2100> seb128: will do! Thanks <seb128> yw! <sil2100> seb128: https://code.launchpad.net/~sil2100/unity-lens-videos/unity-lens-video-precise <- I pushed here again <mhr3> sil2100, btw for lenses != music, you'll just patch the icon paths? (/me hopes he doesn't need to do releases because of that) <sil2100> mhr3: no, I just patched those <mhr3> \o/ <sil2100> didrocks: just a quick question - if there is a green signal from everyone about unity stack trunk freeze, you're able to freeze it for a day? Or is there someone else I'll have to ask then? <didrocks> sil2100: no, just tell me when to freeze :) <didrocks> sil2100: and tell me for which projects I need to freeze <didrocks> (once ok) <sil2100> didrocks: thanks! For now I need to resolve this ibus issue though... need Trevinho for that best <didrocks> mhr3: it sucks to have to change the image path name btw at every new major version of unity <didrocks> yep :) <mhr3> didrocks, indeed, thoughts on where to centralize it? <didrocks> mhr3: I don't get why the path need to be versionned in fact <mhr3> didrocks, that makes two of us :) <MCR1> Hi :) Who is maintaining the Unity-team/staging PPA quantal ? Unity is broken there: Depends: compiz-core-abiversion-20120305 <didrocks> mhr3: \o/ <didrocks> MCR1: the ppa is automatic <mhr3> didrocks, perhaps a "current" symlink if nothing else ? <didrocks> MCR1: as told on it, it can have temporary ABI break and shouldn't be used <mhr3> didrocks, i mean instead of the version number <didrocks> you want a symlink to the current version number? <didrocks> I'll try to start the discussion and discuss about that <mhr3> whatever to get of it <didrocks> and maybe we can discuss even more about the discussion <sil2100> didrocks, mhr3: maybe we'd like to have that for this release? <didrocks> :) <didrocks> sil2100: no, the timing is too short <mhr3> sil2100, yea... i don't think all of us are that fast :) <didrocks> sil2100: let's transition, and maybe transition again <sil2100> didrocks: ok <didrocks> (from 5 to 6 to I hope unversionned) <MCR1> The PPA also features a new Compiz version I would like to try to give feedback on fixed bugs, but the ABI break makes it impossible to test Unity with it :( <didrocks> MCR1: yeah, you need to ensure you have compiz and unity built against the same ABI version <didrocks> the ABI break should be transient and fixed automatically when you get the next unity rebuild <sil2100> hm, the nux/unity fix for ibus that Trevinho is recommending seems to change the nux API <didrocks> MCR1: that's why I put this stenza on the ppa description: <didrocks> This archive contains the latest builds generated from trunk, that have passed the unit tests, but didn't pass the user acceptance (autopilot) tests yet. <didrocks> Unless you are a developer and know what you do here, you should probably use the "unity-team/ppa" instead. <MCR1> Will it work if I build Unity from source ? <didrocks> MCR1: yeah, get the compiz from the ppa, install the -dev package and rebuild unity from source <didrocks> or wait for the next unity version coming to the ppa <MCR1> ok, thx a lot 4 the info. <didrocks> MCR1: yw :) <didrocks> sil2100: not an issue, you plan to merge the nux bump to version 3, right? <didrocks> I still didn't see the packaging changes for it <didrocks> and the branch isn't merged yet but I think it's on your roadmap <sil2100> didrocks: I have it all prepared locally, since I'll have to refresh it when the freeze is on <didrocks> sil2100: hum, you don't have the branch which defines the API version 3, right? <sil2100> didrocks: right now I can't do anything because I don't know if any important changes won't need to be merged in <didrocks> it's not merged AFAIK <didrocks> so not sure what you prepared <sil2100> didrocks: it's not, since it's waiting for right-before-the-freeze - since nux and unity need to have the 3.0 change merged in the same time, otherwise unity auto-merger won't work <didrocks> sil2100: yeah, but it doesn't need to be right before the freeze <didrocks> you do the nux work, push the branch, approve the merge <didrocks> then, you do the unity work, push the branch, approve the merge <sil2100> didrocks: but with unity and nux we still wait for the ibus fix to get reviewed <didrocks> sil2100: that's not a pre-requesite to this change, right? <MCR1> Is there a wiki or even better a script somewhere that helps me with building Unity from source ? <sil2100> didrocks: yes, but we want unity to be able to perform auto-build after merging the ibus fix, right? <sil2100> didrocks: once I merge in the 3.0 changes it won't build <sil2100> didrocks: or does the autobuilder use the nux trunk for building unity? <didrocks> sil2100: why? <didrocks> sil2100: it always take the new version of everything <didrocks> we won't be able to do without it otherwise <sil2100> didrocks: so it's not using -proposed? Just fresh from the trunks? <didrocks> remember my "local repo" I showed and emphasized many teams during the week sprint :) <didrocks> yeah <didrocks> they are constantly adding API, without that, the merger won't work <sil2100> Still, since we want to release a new tarball, I'd like to have all the changes in the tarball <didrocks> sil2100: what's the link with that? <sil2100> So, if I release the new tarball now, and then add the ibus fix, I'll have to add it as a patch, right? <didrocks> I don't speak about a release <didrocks> I'm speaking about 2 branches to merge <didrocks> to bump the new api <didrocks> and also, about the packaging update you need to do for it <sil2100> Ah, k <didrocks> you can do that right now instead of waiting on the ibus fix :) <sil2100> I was talking about the packaging update <didrocks> packaging udpate != tarball <didrocks> so, what you need to do: <sil2100> But on the other hand, I could probably for now just do a packaging update with normal patches <didrocks> - ensure jay's nux branch is ok, pushing an updated packaging for version 3, approve the nux merge <sil2100> And then just release everything as a new tarball <didrocks> - ensure jay's unity branch is ok, pushing an updated packaging for version 3, approve the unity merge <didrocks> and that's it <sil2100> Well, we were already testing Jay's branch <didrocks> why are you speaking about patches? :/ <sil2100> Since my ppa uses nux 3.0 now anyway <didrocks> I'm speaking about merge in trunk <sil2100> Yes, but with the merge to trunk we need to do a merge to packaging too, right? <didrocks> but they are not merged in trunk, right? <didrocks> yeah <didrocks> that's why I'm telling, doing it now <didrocks> and approving the trunk merge <sil2100> They are not, but those won't work if you don't merge into packaging, right? <didrocks> now <didrocks> :) <sil2100> So that's why I'm taalking about packaging <didrocks> 11:41:57 didrocks | - ensure jay's nux branch is ok, pushing an updated packaging for version 3, approve the nux merge <sil2100> That's what I'll do now <didrocks> and same for unity <didrocks> thanks :) <didrocks> ping me to review your packaging update <sil2100> As I said, we already tested nux 3.0 <didrocks> and that I push it <sil2100> So it'll just be an easy task <didrocks> great <didrocks> sil2100: there is no difference than any other package update <didrocks> you see that I'm updating a lot the packaging in advance of time <didrocks> like because of new files <didrocks> or because of path changes <didrocks> that's exactly the same case here <didrocks> (or new build-dep) <sil2100> didrocks: sorry about that, now when I think about it I could have really just pushed it sooner <didrocks> sil2100: no worry, hope you get it now ;) <didrocks> it's really like any other package update <sil2100> didrocks: I just seemed to got locked-up in the idea that I need to wait with the packaging for the tarball <didrocks> sil2100: fortunatly not :) <sil2100> didrocks: that it doesn't make sense to push it now if the tarball will be released later ;p <didrocks> sil2100: at least, we will get this hopefully merged and built before trevhino is here for the ibus thingy <didrocks> just ping me with the package update <sil2100> didrocks: the thing is that I thought that it's not good to do it without the new tarball - since we're essentially changing the name to nux-3.0, where the version number in packaging will be still 2.* <didrocks> sil2100: no <didrocks> sil2100: you are changing the packaging now <didrocks> and we will push it just before setting the merge proposal to approve <didrocks> and so, we will get the new packaging :) <sil2100> Just to get this straight - can I change the major number of the nux version to 3 ? <sil2100> In packaging? <sil2100> Since normally, when changing the major number, I was doing a merge-upstream with the new tarball <sil2100> didrocks: ^ ;) <didrocks> sil2100: right <didrocks> sil2100: change the packaging and push it to me :) <MCR1> didrocks, regarding: https://code.launchpad.net/~mc-return/compiz/compiz.merge-plugin-stackswitch/+merge/111736 - do you mean our discussion here ? <didrocks> MCR1: no, was in private with duflu <didrocks> (PM) <MCR1> ah, ok - *confused* <sil2100> didrocks: https://code.launchpad.net/~sil2100/nux/ubuntu-3.0 <- ;) ? <sil2100> brb <didrocks> MCR1: basically, we are using the packaging to build an upstream source to push to the ppa, as you added some files and nobody updated the package, it failed <didrocks> MCR1: now, it's fine <MCR1> didrocks: I am working on getting *forgotten* plug-ins to lp:compiz, we did not have that problem with workspacenames though <MCR1> but if it is fine now, it is great 8-) <MCR1> thanx <didrocks> yw :) <didrocks> sil2100: looks good to me :) <didrocks> sil2100: pushed, you can ack the nux merge now <sil2100> didrocks: approved <sil2100> (commit message was missing) <sil2100> ;) <didrocks> sil2100: well, you approved it before pushing the branch, thanks god you forgot the commit message :) <sil2100> didrocks: I did? I think I did that by accident - damn, good for that missing commit message... <sil2100> didrocks: eh, conflict <sil2100> Oh, right, but I can push to that branch actually <sil2100> Fixing <MCR1> Yeah, my second contribution to Ubuntu/Compiz: http://bazaar.launchpad.net/~compiz-team/compiz/0.9.8/revision/3277 <MCR1> :) <MCR1> btw, I also got a contribution for Unity: https://code.launchpad.net/~mc-return/unity/unity.merge-reduce-png-filesizes/+merge/110978 <didrocks> MCR1: sweet! let's wait for upstream to review them :) <didrocks> MCR1: btw, about the recompression, we already have that automatically on the binary package <MCR1> didrocks: It is nothing special, but probably should be done <MCR1> your png files are not compressed very well <MCR1> I used Trimage image compressor to optimize them <MCR1> ofc more could be done <MCR1> most of the files could use indexed colors as well (8bit instead of 24+8bit) without any visual regression as most of the files do not use more than 256 colors anyway <MCR1> and alpha is empty <sil2100> didrocks: I also prepared a distro branch for unity 6.0 with the new nux: https://code.launchpad.net/~sil2100/unity/ubuntu-6.0 <sil2100> But nux is still building <MCR1> didrocks: You can check it yourself: simply install the package trimage and drag and drop all .png files there <didrocks> MCR1: hum, weird, we maybe have dh_scour which is broken then <MCR1> didrocks: you will save around 80kB <didrocks> sil2100: well, that's fine, we can ack it now <didrocks> sil2100: as my dep system is working :) <didrocks> sil2100: FYI, I'm merging you content <didrocks> sil2100: as you didn't get the latest unity packaging branch <MCR1> Once I got my build and test system for Unity/Compiz working here I plan to help with fixing more important stuff as well :) <didrocks> sil2100: libnux-3.0-dev (>= 3.0.0-0ubuntu1), is somewhat wrong as a build-dep <didrocks> MCR1: sweet! <didrocks> sil2100: better to take 3.0.0 to enable backporting <didrocks> sil2100: I'm fixing that <sil2100> didrocks: ah, ok, sorry about that <didrocks> sil2100: and you dont' want to bump the version yet on that case :) <sil2100> You mean, unity to 6.0? <didrocks> sil2100: yeah <didrocks> do that once you will release :) <didrocks> sil2100: pushed to lp:ubuntu/unity <didrocks> you can approve the MR <sil2100> Why not now? Since I already bumped the version for nux to 3.0, right? So we theoretically could have done the same for unity? <didrocks> sil2100: because merge-upstream won't be happy <didrocks> sil2100: I didn't change it for nux but it should have been 3.0~something <didrocks> sil2100: because now, the version in the staging ppa are higher than the revision that would be in the distro <sil2100> Ah, right, we'll have to do the trick you did with compiz on the sprint <didrocks> it will be 3.0+bzr<foo> <didrocks> even if they are older <sil2100> Right <sil2100> didrocks: the tests failed for the unity nux-3.0 branch <sil2100> Could not open X display? <didrocks> sil2100: there is no X in the merger <sil2100> xvfb? <didrocks> yep <didrocks> sil2100: you should check that with upstream <didrocks> seems a test is flacky or broken with the new nux :) <sil2100> But it doesn't even say which test failed, geh <sil2100> I'll pick this up with Jay once he's back <didrocks> sil2100: well, all the output is from upstream, they should fix it to tell which one :) <sil2100> Annoyiiiing! <sil2100> ;) <didrocks> heh ;) <sil2100> seb128: how's the unity-lens-video SRU branch? Was it ok? <seb128> sil2100, sorry I was out when you pinged and I got busy, I will have a look now <sil2100> seb128: thanks <seb128> sil2100, yw! <sil2100> Trevinho: regarding that ibus fix <sil2100> Trevinho: was that something that got recently introduced? That it's broken? <sil2100> Trevinho: and I see you modify the nux headers <Trevinho> sil2100: we had some issues... first of all we didn't properly filter the meta keys in textentry, also we didn't support ibus release activation key... so I wanted to change the thing from nux... <sil2100> Trevinho: well, I'm waiting for Brandon as well to be honest - I have some bug-related things for him! <sil2100> But anyway, I think that it would be REALLY nice to have this ibus thing fixed with 6.9 <sil2100> *6.0 <sil2100> So I'd say it's a bit of a blocking issue - although if jaytaoko will think that it's a risky change or something, we'll then release without it <Trevinho> sil2100: code is fixed... so... we only have to get it in trunk :) <sil2100> Trevinho: ;) <didrocks> Trevinho: is it a regression from 5.x ? <sil2100> Trevinho: but commits on both sides are needed, right? Bot the nux and unity side <Trevinho> didrocks: mhmh a little... I pushed a different branch in 5.0 that fixes the key filtering without changing nux and being a little bit permissive to avoid breakage... <Trevinho> sil2100: yes, we need both nux and unity <didrocks> sil2100: so it's a regression, and we won't take it into quantal without the bug fixed :) <jaytaoko> Trevinho: so you are trying to get your branches in for this release? <sil2100> didrocks: so it's, like I said, a blocking issue then? But for reals ;) <sil2100> jaytaoko: well, it seems to be an urgent fix then <didrocks> well, it is, right, no regrssion for us <didrocks> should have been dealt earlier, but well <Trevinho> didrocks: yes I opened a bug to track it since I discovered: https://bugs.launchpad.net/unity/+bug/1016354 <ubot5> Ubuntu bug 1016354 in unity "IBus can't be activated on dash or HUD since r2428" [High,In progress] <Trevinho> jaytaoko: we should yes <jaytaoko> sil2100: as I said to Trevinho before, the code looks fine. But I was hoping bschaefer could give a second opinion because I don't know the details of the issues <jaytaoko> sil2100: bschaefer is not awake yet I think (eastern US) <sil2100> jaytaoko: could you test build it and see if it doesn't break anything obvious? <jaytaoko> sil2100: sorry bschaefer is in western US <jaytaoko> sil2100: sure <sil2100> jaytaoko: thanks! <didrocks> sil2100: also, do you know about the compiz release status? <didrocks> as Timo is doing it <sil2100> didrocks: not sure, I knew he was busy yesterday, but I'll ask him in a moment <didrocks> sil2100: keep me in touch please :) <sil2100> didrocks: for bug #1016354 , should I also attach nux and the nux branch? <ubot5> Launchpad bug 1016354 in unity "IBus can't be activated on dash or HUD since r2428" [High,In progress] https://launchpad.net/bugs/1016354 <sil2100> Since essentially it's being fixed by two merges <sil2100> In unity and nux <didrocks> sil2100: yeah <jaytaoko> sil2100: the nux branches compile but I am getting errors in the tests <jaytaoko> sil2100: so as it is, we cannot merge this branch just yet: lp:~3v1n0/nux/text-entry-virtual-clipboard <jaytaoko> Trevinho: ^^^ are you getting errors will running "make check" for the branch? <Trevinho> jaytaoko: mmh, I'll try... but my tests run fine <sil2100> hmm <Trevinho> jaytaoko: what's failing there? <jaytaoko> Trevinho: http://pastebin.ubuntu.com/1073170/ there are more test failing... <jaytaoko> Trevinho: I am trying nux trunk... <sil2100> Trevinho: we merged in some nux-3.0 changes in trunk <sil2100> Trevinho: are you trying it on trunk..? <Trevinho> jaytaoko: mhm weird... they all passed here yesterday... * Trevinho checks <Trevinho> kamstrup: ok.. found the issue... when ibus-daemon is running some of them fails... maybe I should fix that <leo-unglaub> i have a problem with the current nightly of unity.. <leo-unglaub> installed via the ppa http://ppa.launchpad.net/unity-team/staging/ubuntu <leo-unglaub> this is now trying to triggern an dist-upgrade <leo-unglaub> witch failes.. <leo-unglaub> it always means that there is no ubuntu-desktop package found <leo-unglaub> but the meta package is installed <leo-unglaub> if i do the upgrade from the sell myself, it works fine <leo-unglaub> just so you know this bug.. <leo-unglaub> if you need any additional informations, please let me know <sil2100> Trevinho: how's the test issue? <Trevinho> sil2100: I'm fixing now... some tests fails when ibus-daemon is running <Trevinho> sil2100: I didn't think to that since I thought that make check was running without ibs <Trevinho> ibus* <sil2100> Trevinho: excellent! Thanks <sil2100> andyrock: hi! <sil2100> andyrock: are you around? <andyrock> sil2100, yeah but i'm studying <andyrock> do you want me to SRU something? <sil2100> andyrock: well, nothing urgent ;) <andyrock> sil2100, shoot! :) <sil2100> andyrock: I was wondering maybe if the fix for bug #934062 is SRUable as well ;) <ubot5> Launchpad bug 934062 in unity (Ubuntu) ""Keyboard Shortcuts" overlay can cause annoyance" [High,In progress] https://launchpad.net/bugs/934062 <andyrock> sil2100, yes it's SRUable <andyrock> have we the SRU freeze today? <sil2100> andyrock: no, today was supposed to be quantal freeze, but we'll do that tomorrow <andyrock> so i can SRU it this evening... <andyrock> i can ask someone to review it <sil2100> andyrock: the SRU freeze will be probably be around end of the week if anything <andyrock> cool <andyrock> so i think i have to SRU 2-3 branches <sil2100> andyrock: ooo, thanks! ;) <andyrock> np <seb128> sil2100, davidcalle: video lens new SRU uploaded, thanks <davidcalle> seb128, thank you <sil2100> seb128: thanks \o/ <jaytaoko> Trevinho: areyou getting the test errors? <Trevinho> jaytaoko: only when enabling ibus-daemon <Trevinho> jaytaoko: however, I've fixed the first branch... <Trevinho> jaytaoko: fixing the second now <jaytaoko> Trevinho: ok <Trevinho> jaytaoko: this should be fine for merging, tough https://code.launchpad.net/~3v1n0/nux/text-entry-meta-filters <jaytaoko> Trevinho: ok. so I need to get two nux branches, right? <jaytaoko> Trevinho: first lp:~3v1n0/nux/text-entry-meta-filters and then lp:~3v1n0/nux/text-entry-virtual-clipboard <Trevinho> jaytaoko: there were two branches... with dependency <Trevinho> jaytaoko: yep <jaytaoko> Trevinho: right! so I am merging them with nux trunk before compiling <sil2100> didrocks: if we get this ibus fix merged into unity and nux, would you mind doing the freeze tomorrow? <didrocks> sil2100: sure, a pity that wasn't dealt before <didrocks> sil2100: or we can freeze now <didrocks> then, they get the release critical branches with "UNBLOCK" <didrocks> which can be the case of the ibus onces <sil2100> didrocks: that wouldn't be a problem? <sil2100> i.e. freezing for a whole night? <Trevinho> didrocks: sorry, I should have done this before... But I wanted to finish other stuff.. <Trevinho> jaytaoko: the problem with tests when ibus is running is that... we use an async call to check if an event has been filtered... this can cause troubles, since we always return true in IBusIMEContext33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abilterKeyEvent <jaytaoko> Trevinho: are your branch fixing a release critical issue? <Trevinho> jaytaoko: well, the ibus break is critical... <jaytaoko> Trevinho: hmm! that is why I think we should get bschaefer <Trevinho> jaytaoko: I agree <jaytaoko> sil2100: how much trouble is it for you to postpone the release? <didrocks> sil2100: as you wish for the time of freezing <didrocks> sil2100: just hope that they won't introduce regressions if we don't freeze :) <sil2100> jaytaoko: well, hm, we had plans on releasing unity stack this week <sil2100> jaytaoko: how much more time do you need? <jaytaoko> sil2100: it is to leave time for bschaefer to have a look at the branches before they are merged <bschaefer> jaytaoko, have a look at which branches? <sil2100> jaytaoko: this can be done - would you ensure that Brandon looks at those today? <sil2100> Ah! <sil2100> ;) <sil2100> bschaefer: hi <bschaefer> sil2100, hello! <jaytaoko> bschaefer: hello <bschaefer> jaytaoko, hello, and good morning haha <jaytaoko> bschaefer: can you review these branches: https://code.launchpad.net/~3v1n0/nux/text-entry-virtual-clipboard/+merge/113145 <bschaefer> yes <bschaefer> jaytaoko, let me take sometime to run some test on it <sil2100> bschaefer: thanks <bschaefer> sil2100, np! <sil2100> jaytaoko, bschaefer: could you guys try merging the tested fix till tomorrow? <sil2100> Since then we'll just do the release tomorrow <bschaefer> till tomorrow or by tomorrow? <sil2100> didrocks: would you prefer to freeze today? You have more experience here ;) <sil2100> bschaefer: so that it's merged in by tomorrow morning <sil2100> bschaefer: since we need this fixed for the release, it's currently a blocking issue <bschaefer> sil2100, yup, its 8:30 am here, Ill make sure it is merge by then <sil2100> bschaefer: \o/ <jaytaoko> bschaefer: and run the "make check" please. <bschaefer> jaytaoko, will do! <sil2100> Damn, a nasty storm here <Trevinho> hi bschaefer <bschaefer> Trevinho, hello! So far these changes look nice :) <Trevinho> bschaefer: for the 2nd one (virtual clipboard) wait few seconds since I've failing tess when ibus-daemon is running * bschaefer broke is pinyin <bschaefer> Trevinho, alright, Im installing it right now <didrocks> sil2100: it's really as you wish ;) if you don't care about redoing all the tests tomorrow, it's fine to only freeze tomorrow <Trevinho> bschaefer: they fail due to the fact that ime_>FilterKeyEvent is async (which is good), but it desn't give us the event <Trevinho> but I guess that adding some timeout would fix it <sil2100> didrocks: so hm, is it a big bother to freeze the trunk now? <sil2100> bschaefer, Trevinho: would you mind? <sil2100> I would ask for a freeze now, and unfreeze it around tomorrow <bschaefer> Trevinho, hmm that sounds like a good fix for that...could you do an idle to wait for it? <didrocks> sil2100: ask upstream :) <bschaefer> that might slow it down though <sil2100> And the ibus fix would be added as an UNBLOCK <bschaefer> Trevinho, hmm I just got a compiling error <sil2100> bschaefer: ^ ? <sil2100> Trevinho: ^ ? ;) <bschaefer> Trevinho, http://pastebin.ubuntu.com/1073278/ <sil2100> Would you guys mind a freeze with the current state of trunk? <sil2100> + the ibus patch when ready? <bschaefer> Trevinho, you missed a comma in the printf <jaytaoko> Trevinho: make check fails to build <Trevinho> probably I've pushed a bad version :o <Trevinho> bschaefer: which branch? * sil2100 feels ignored while there is thunder near his apartment <sil2100> ;) <bschaefer> Trevinho,
{'channel': 'ubuntu-unity', 'month': 7}