[08:26] sil2100: hey [08:27] sil2100: what's the status about unity/dee/the stack release for quantal? [08:34] didrocks: we were testing the nux + unity + lens, ETA for the stack is for tomorrow [08:35] didrocks: should the unity devs be based on quantal now? [08:35] sil2100: ok, I think your coordinated this with upstream, right? and have a versionning with bugs that are closed/new features :) [08:35] or is it still ok to be precise? [08:35] thumper: I guess they should, some code was committed in compiz not compatible with the newer boost for instance [08:35] thumper: quantal is quite stable, didn't get any "no X, no sound" issue [08:36] didrocks: orly? like what? [08:36] thumper: I can find it back if needed, but can't happen anymore now. I added automerging to compiz [08:36] \o/ [08:36] not entirely necessary [08:37] I was just curious [09:52] didrocks: I hope I do... === yofel is now known as Guest57033 [10:19] 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... [10:19] sil2100: well, I want the overrides thing, then, check with upstream about the better plan for them :) [10:19] ACK [10:20] mhr3: could you comment on that ^ ^ [10:23] let me check the changes [10:27] mhr3: I just see the overrides thing and one debugging thing [10:27] mhr3: nothing more [10:28] sil2100, right, so you're basically going to sru current trunk :) [10:28] mhr3: not only SRU - also a quantal release [10:29] mhr3: so, we can stick with the current tarball? [10:29] sil2100, up to you really, if you say you want new tarball i'll make it [10:31] 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)? [10:32] sil2100: if you are not doing a new tarball, please don't cherry-pick the bump [10:32] didrocks: ok [10:32] this is confusing then that the package version doesn't match the library one [10:33] 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 [10:33] mhr3: so I'll just cherry-pick those [10:34] sil2100, as you wish [10:42] mhr3: btw. is the whole dee trunk SRUable? Or are there any commits on there that I should not cherry-pick? [10:43] sil2100, you can take everything [10:43] minus the bump as didrocks said [10:44] mhr3: excellent, thanks! [10:56] sil2100, are you rebuilding lenses with latest vala in quantal? [10:56] mhr3: I think I will have to I guess - is there some work involved with it? [10:57] they'll probably start crashing [10:57] 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? [10:57] not right away, we just saw music lens does after activating an album [10:57] dee doesn't care about vala [10:57] Good [10:58] hm [10:58] didrocks: can we stick with the old vala with the lens for now? [10:58] Since I see you started the switch for libunity already [10:58] mhr3: ah! see it's not stable [10:58] seb128: FYI, you were telling the new vala world was great^ [10:59] mhr3: can we keep libunity with the new vala? [10:59] as it's fixing the gir bug [11:00] mhr3: sil2100: unity-lens-music is building with vala 0.14 [11:01] didrocks, i thought you moved everything to 0.18 for Q? [11:01] mhr3: not everything :) [11:01] didrocks, so what was moved? [11:01] just libunity? [11:01] mhr3: yep [11:02] mhr3: the crash happens with the package? [11:02] didrocks, it's ulm-specific [11:02] doesn't tell me if it's with the package :p [11:02] didrocks, but i can't really tell if the switch in libunity will introduce more crashes [11:03] i didn't see anything too bad here, but i've been just running some tests, not real system [11:03] mhr3: but this ulm crash, it's not the package right? [11:03] just if you build locally with latest vala? [11:03] didrocks, no, it'll happen if you rebuild current src wih 0.18 [11:03] ok, you got me scared ;) [11:04] mhr3: let's see and try libunity with vala 0.18 [11:04] and keeping the rest/upgrading to 0.16 [11:04] sil2100: ^ [11:04] mhr3, didrocks missed beginning of your discussion, but the sooner we switch the better, even if it crashes a lot... [11:04] didrocks, agreed, that's the only way to see what happens :) [11:04] pstolowski: no [11:04] pstolowski: we won't push into ubuntu versions that crashes [11:04] didrocks: ACK [11:04] So 0.18 for libunity, rest - the old one? [11:05] didrocks, oh, wait, 0.16 will crash as well [11:05] only 14 is safe for lenses atm [11:05] sil2100: yeah, apart if when you do the package upgrade, you see a lot of crashes [11:05] mhr3: ok, so keeping 0.14 for lenses [11:05] which is what they are on [11:05] fine [11:05] sil2100: so, basically, you have nothing to do :) [11:05] there's still the icon path 5 -> 6 [11:05] sil2100: just ensure if you do a local build (not in pbuilder), that you selected the right update-alternatives valac version first [11:05] One moment, meeting [11:14] mhr3: I fixed that locally, so I'll just re-do and push [11:14] didrocks: when I'm done, I'd like to confirm some things ;) [11:14] (done with the meeting) [11:20] didrocks, re, I was at lunch ... what's up with vala? ;-) please use 0.16 or 0.18 if you can [11:21] seb128: we can't [11:21] crashes with both [11:21] for lenses [11:21] that's just the ping was about :) [11:21] oh [11:22] didrocks, that's likely a bug in mhr3's code! [11:22] seb128: agreeing ;) [11:22] seb128, didrocks but it's because they keep changing vala behaviour :P [11:22] * didrocks heard one week before that "vala was really stable now, nothing to fear, blablabla" from 2 people here ;) [11:23] lol [11:23] didrocks, you got me now :P [11:23] \o/ === MacSlow is now known as MacSlow|lunch === fenris_ is now known as Guest20501 === _salem is now known as salem_ === mhall119_ is now known as mhall119 === MacSlow|lunch is now known as MacSlow [13:25] Ok everyone, I would like to release a new unity stack for quantal around tomorrow - any objections to that? [13:27] mhr3: think we should wait till after release before merging in the preview api branch to unity core? ^^? [13:30] gord, well, it's just api, and not hooked up, so it could go in imo [13:30] It won't break anything? [13:30] Since I'd like to ask for a trunk freeze for tomorrow [13:32] shouldn't do [13:33] anyhow, someone will have to approve the branch first :) [13:40] needs to wait for QA to re-review, yell at thomi tonight and maybe it'll get merged in before the morning [13:40] Well, I do hope that tomorrow we'll have a freeze, since otherwise packaging work is a bit pointless [13:40] i think qa is broken atm, cause i pushed and it didn't re-complain [13:41] i mean thomi did a review already and wanted some changes right? [13:41] not the qa lab stuff [13:41] the qa lab stuff is just dice rolling [13:41] ah, no, marco was looking at it [13:42] Trevinho, so feel free to re-review now ;) [13:42] hum, you are right. whos review am i thinking of.. [13:46] 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 [13:46] Ubuntu bug 904205 in Compiz "Desktop wall: Bindings for next/previous don't wrap to the next row" [Wishlist,In progress] [13:47] Klap-in, hey, yes it seems to be fine for a SRU [13:47] Klap-in, but it needs to be reviewed,commit first [13:48] Klap-in: could you submit a merge request? Probably best for both compiz trunk and compiz-plugins-main [13:49] sil2100: ok, i did a merge request on the compiz-plugins-main [13:49] on the default, thus on the devel branch. [13:50] Klap-in: ah, see it now, thanks === Guest57033 is now known as yofel [13:50] Klap-in: we'll try having that reviewed [13:50] is a extra mergerequest on compiz usefull? [13:51] 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 [13:52] 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 [13:57] sil2100: ok, then i do also a merge request on compiz === zyga is now known as zyga-food [14:10] mhr3: you was referring to the ap fix branch? or to the previews one? [14:11] Trevinho, the latter [14:12] mhr3: ok, looking at the introspection bamf... [14:12] mhr3: I guess we had a bug about it to link... [14:13] Trevinho, hmm, i'm still wondering if there should be two girs (one for gtk2) [14:14] mhr3: probably yes... [14:14] do we care about gtk2? :P [14:14] it's not like introspection worked too much there :) [14:15] mhr3: I mostly did on the code... there was some projects depending on libbamf (not 3 version) === dandrader is now known as dandrader|afl === dandrader|afl is now known as dandrader|afk === zyga-food is now known as zyga [14:26] 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...]) [14:28] Trevinho, that's why the annotations are in the .c files, so they can be easily updated when the method changes [14:34] 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? [14:34] sil2100: would be nice to do a release for this one I guess [14:36] didrocks: a new tarball, yes? [14:36] ACK [14:36] mhr3: bamf_matcher_get_active_window could return null (if not connected to the daemon or other odd cases) [14:36] didrocks: so maybe we'll SRU it as well? [14:36] sil2100: hum, no [14:36] sil2100: how do you want to SRU that? [14:36] it's a new feature :) [14:37] didrocks: ok - just saw bugs linked to it like 'unknown albums might bla bla' so I thought it's a bugfix too [14:37] sil2100: it is, but it adds translations [14:38] sil2100: as if you looked at merge request content would have tell you ;) [14:38] sil2100: you really need to start looking at those! [14:38] didrocks: I know I know! But asking first never hurts! ;) [14:39] Besides, I have yet to master vala [14:39] As my vala-foo is weak [14:40] sil2100: well, you really don't want to :p reading is easy, writing is less IMHO :p [14:40] 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? [14:40] For the assets [14:41] Or should I leave it as 5 and just do a patch with switching to 6? [14:42] Trevinho, actually i didn't use that properly, gir specifies nullable only for method parameters [14:42] hm, crap, I'll have to submit merge requests to all the lenses :| [14:42] Trevinho, pushed fix [14:42] sil2100: don't move it if it's not necessary to move it [14:43] mhr3: oh, yes... so we can avoid to specify that [14:43] didrocks: so a patch? [14:44] implementers should always perform null checking... [14:44] sil2100: if upstream moved it, move them [14:44] if not, don't :) [14:45] 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 [14:45] But it will have to sooner or later [14:45] Anyway, I'll release the tarball in the state the trunk is now [14:45] sil2100: good :) [14:46] And then just proceed normally ;) [14:46] didrocks, you evil little you, don't discourage sil2100 from writing patches for us :P [14:46] mhr3: ;) [14:46] mhr3: you want to roll-out the new tarball, or should I do it? [14:46] mhr3: for the music lens? [14:47] you want a tarball? [14:47] did we actually have changes? [14:47] mhr3: I am that evil! [14:47] mhr3: you have awesome changes [14:47] in the music lens [14:48] didrocks, of course we do :) [14:48] sorry didn't notice your stuff got merged already [14:49] mhr3: I see how deeply sorry you are, that's fine :-) [14:49] omg! [14:49] a see a tab in the diff [14:49] how could you?! [14:50] !!! [14:50] BURN THE TABBER [14:50] RED, cannot release! Tab in the diff! [14:52] mhr3: in lp:~mhr3/unity/update-core-preview-api what about using std::unique_ptr for pimpl? (just to be more C++11 :)) [14:52] Trevinho, can't, it doesn't compile [14:53] mhr3: yes, you just need to keep an empty destructor [14:53] mhr3: keep the ~Class(() {}... and it will work [14:53] Trevinho, for the Impl? [14:53] Trevinho, or the Preview subclasses? [14:53] mhr3: no, for the wrapper class [14:55] sil2100, so i suppose that would be ulm 6.0? [14:56] mhr3: hm, not sure [14:56] mhr3: ...probably? [14:57] sil2100, and should i bump the icon path in the .lens file as well? [14:57] 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 [15:01] mhr3: so I think yes [15:11] crap [15:11] i almost tagged bamf instead of ulm [15:14] sil2100, anyway tarball up [15:21] mhr3: \o/ Thanks! [15:22] sil2100, btw when producing tarballs i push straight to trunk without the mergers, that's how we used to do it with didrocks [15:23] not sure what/if that changes anything for you [15:30] mhr3: not really, it's ok for me too [15:35] Trevinho, pushed unique_ptrs [15:36] mhr3: good ;) [15:36] and i continue to think c++ is stupid :) [15:39] i would expect it to have proper error messages after being developed for 20+ years [15:43] but i suppose they're too busy having to implement glr parser :P [15:54] didrocks: new tarball imported (new upstream release) in packaging for ulm: lp:~sil2100/unity-lens-music/quantal_PRE [15:56] sil2100: please, prepare everything and I will review when everything is ready [15:56] and that you have tested and so [15:56] didrocks: ACK [15:57] Well, I have almost everything else prepared too, just waiting for the possible trunk freeze tomorrow for unity and nux [15:57] So that I won't have to re-do all the work [16:17] mhr3: regarding libunity - you want to release a new tarball, or you think it's too early? === zyga is now known as zyga-afk [16:22] sil2100, we released 5.90 already [16:22] although i should do a new one [16:22] sil2100, give me a moment [16:23] mhr3: with this one we're switching to the new vala, so maybe a new release would be good [16:24] Actually, hmm [16:26] hmm at very least make check passes with latest valac :) [16:27] didrocks, weren't you going to patch libunity to ship the gir or something? [16:27] mhr3: we did it [16:28] but wanted to remove it [16:28] as the latest valac fixed it [16:28] (so removed in the package) [16:28] didrocks, but wasn't the gir missing for -dev? [16:28] s/for/from/ ? [16:28] mhr3: it's in now [16:29] but it should be there anyway, no? [16:29] Ok, so no new tarball for libunity? [16:29] sil2100, it's on the way [16:29] we ship 5.12.0-0ubuntu2 in quantal [16:29] with the gir fix [16:30] 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 [16:30] 5.90 was something I wanted that we do during the sprint [16:30] mhr3: no, you did understand me very well, but in this case, it was more "blame the packager", but shhhh :) [16:31] heh ok :) [16:31] ...me? ;) [16:32] no, was me :p [16:34] sil2100, released [16:35] sil2100, btw i'm evil and doing post-release bumps, you shouldn't push those to distro ;) [16:35] Heyo folks. Just wanted to raise bug 1020115 to attention. It affects the latest update-manager [16:35] Launchpad bug 1020115 in unity (Ubuntu) "Spawned commands can't use pkexec" [Undecided,New] https://launchpad.net/bugs/1020115 [16:36] seems like a mhr3's bog! ;-) [16:36] seb128, you knew something about that though, didn't you? ;) [16:37] mhr3, me? no, you must confuse me with somebody else [16:37] ;-) [16:37] seb128, your jedi tricks won't work on me :P [16:37] :-( [16:40] mhr3, that would likely be a bug in the app lens right? [16:40] Holy shit, bzr merge-upstream just crashed [16:41] seb128, it happens even from indicators [16:41] mterry, glib doing? g_spawn_...? [16:41] seb128, well... we just use glib, so... [16:42] seb128, I wouldn't think it would set ppid to 1 automatically [16:43] seb128, strangely synaptic uses it, but it's executed from a wrapper script [16:43] (and works) [16:43] mhr3, mdeslaur added it to synaptic with that comment [16:43] "- debian/rules, debian/synaptic-pkexec: install wrapper to work around [16:43] .desktop files not being able to call pkexec directly." [16:44] Did anyone get an error like this before in bzr merge-upstream? [16:44] doesn't really tell why :/ [16:44] NoSuchRevision: CHKInventoryRepository('file:///home/sil2100/Work/canonical/release/libunity/tmpVbvIP4/upstream/.bzr/repository/') has no revision didrocks@ubuntu.com-20120614074747-nnnfjs5hyplbqaj0 [16:45] sounds like it's missing something [16:45] Ah, one moment [16:45] sil2100: never got that, did you -r -1? [16:45] sil2100, try asking #bzr? [16:45] or -r -2 [16:45] Yes, but uno moment [16:45] o [16:45] with the post release bump :) [16:45] mhr3, specifically, ppid is 1. I don't know why unity is causing that, but that's the root cause of the pkexec problem [16:46] mterry, oh [16:46] mterry, glib reaps the child processes by default [16:46] mterry, is that specific to unity or any g_spawn wrapper will do that? you said indicators have the same issue [16:47] didrocks: probably the problem is in the fact that in the distro branch, there's an unreleased version present [16:47] mhr3, ah, so the g_spawn* family does set ppid to 1 automatically [16:47] and when launching a desktop, there isn't really a way to *not* do that [16:47] Aaaa [16:47] No, waaait [16:47] My mistake it seems! [16:47] sil2100: no, it's not the problem [16:47] grrr [16:47] ah ok :) [16:47] sil2100: it seems that you are releasing before testing right? [16:48] 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? [16:48] sil2100: meaning that potentially the tarballs are not working fully/tested? [16:48] so low quality? [16:48] never trust mhr3's tarballs :) [16:48] my tarballs have a "it's a trap" sticker [16:48] didrocks: I'm not releasing anything, I'm preparing everything for testing [16:49] didrocks: I prepare my distro branches so that I can build clean test packages from those [16:49] sil2100: well, mhr3 did the release and published the tarball, right? [16:49] And if it's green, I then just push it to the ether [16:49] mterry, can't say really, maybe :) [16:49] in case the tarball is not good, you would redo all the import? [16:49] mterry, ie perhaps it has a reason :) [16:50] 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 [16:50] didrocks: and if it's not broken, I don't have to do anything but just pushing ;) [16:50] mterry, but as can be seen with synaptic, a simple wrapper script workarounds the issue [16:50] 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 [16:50] mterry, would be good to check with mdeslaur or pitti [16:51] seb128: as long as the tarball is not published into the Internet and no confusion is around :) [16:52] sil2100, ^ [16:52] sil2100, didrocks has tab completion issues ;-) [16:52] It happens to me as well! [16:54] grrrr ;) [16:54] seb128: stop speaking! [16:54] s complete the latest one :) [16:55] didrocks: btw. the bzr merge-upstream problem I had - it seems to be caused by the previously unreleased version [16:55] Since when I removed it, it worked fine [16:55] ok [16:55] Do I need something specific to make it work, or should I just remove the unreleased one and add it as the new one? [16:56] didrocks, that's what you get for asking me to do tarball and then not releasing it! :P [16:56] * sil2100 is confused with all the maddness going on here! [16:56] You guys are crazy! [16:56] ;p [16:56] sil2100, don't worry, it's infectious [16:56] :'( [16:57] you'll be assimilated [16:58] anyway, eod.. cyas [16:58] mhr3: well, blame the sprint :) [16:59] Ok guys, I'm finishing for today as well, time to let the PC cool off from all this afternoon heat-maddness [16:59] See you tomorrow! [16:59] see you sil2100 [17:05] Do developers here have any comment on this: http://www.ubuntuvibes.com/2012/07/unity-revamped-adds-always-visible.html ? === dandrader|afk is now known as dandrader === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === philipballew_ is now known as philipballew === mfisch` is now known as mfisch === mfisch is now known as Guest84007 === dandrader is now known as dandrader|afk [20:44] MCR1: you should probably ask designers... === dandrader|afk is now known as dandrader [20:59] morning [21:18] Trevinho: Where can I find the designers ? ;) [21:19] Is someone here responsible for maintaining the Unity/staging PPA Quantal ? [21:22] Unity in the PPA still depends on compiz-core-abiversion-20120305 and libgnome-desktop-3-2, so it is not installable :( [21:23] I wonder how it passed the unit-tests :-/ [21:31] MCR1: you can ask on unity-design ML, or to JohnLea [21:33] not sure about the daily ppa but the packagers are after their end of work day [21:35] they're all tucked up in bed getting their beauty sleep [21:35] (or should be) [22:12] Trevinho, seb128 thx 4 the infos. === salem_ is now known as _salem