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