[03:01]  * hyperair wishes indicator-sound took control of the media keys.
[03:02] <hyperair> that way media keys could work on youtube videos playing in the background.
[03:02] <hyperair> or grooveshark for that matter.
[09:13] <rperier> Hey, I would like to contribute to the development of unity. I have already discussed with didrocks , he shown me this link http://unity.ubuntu.com/getinvolved/development/unity (thanks to him) . I have also built unity from trunk, I did read a bit of documentation, etc...
[09:15] <sil2100> rperier: hello!
[09:16] <sil2100> rperier: tell me, what Ubuntu version are you currently using?
[09:16] <rperier> I am running 13.04
[09:16] <rperier> at home and 12.10 at work
[09:18] <sil2100> rperier: ok, good, remember that all the unity work that is in lp:unity is related to 13.04
[09:26] <rperier> sil2100: you mean that all the unity used in 13.04 is a daily built from lp:unity ?
[09:27] <sil2100> rperier: yes
[09:28] <rperier> ok it's noted
[09:31] <sil2100> If you want to propose a fix for 12.10 or 12.04, you should consider backporting to lp:unity/6.0 and lp:unity/5.0 respectively - those are the quantal and precise source trunks
[09:53] <rperier> sil2100: ok, there is junior bugs on LP for unity ?
[10:02] <rperier> I code in C,C++ and python (it's is my job), I might be useful :)
[10:02] <smspillaz> rperier: search for "bitesize" tagged ones
[10:03] <smspillaz> they might be out of date though
[10:03] <rperier> ok looking
[10:07] <sil2100> rperier: if the bitesize bugs are out of date, you can always try looking for recent bugs that are low priority and trying to resolve them - that's the best way of familiarizing with the code
[10:19] <rperier> sil2100: I will probably look for recent bugs with low priority. thanks
[13:03] <rperier> unity should depend on bamf 0.4.0 right ? otherwise it causes FTBFS on quantal (at least the build system should ensure that bamf >= 0.4 is found), I am talking about bug 1086276
[13:04] <rperier> this function was added to the trunk branch between the tag 0.3.2 and 0.4.0-daily-xxxxx
[13:34] <sil2100> rperier: let me check
[14:05] <rperier> sil2100: still checking ? :)
[14:17] <sil2100> rperier: ah, sorry! ;) I got preempted to something else, I'll do it in a moment ;)
[14:25] <rperier> sil2100: sure, np :)
[14:33] <sil2100> eh eh, always something to do ;)
[15:05] <sil2100> rperier: ok, so, maybe indeed we should bump the build-system to require bamf >= 0.4
[15:05] <sil2100> rperier: but the packaging already has that dependency
[15:06] <sil2100> So, if unity is being built as part of a package, we're sure that it will fetch bamf >= 0.4
[15:06] <rperier> but if unity is built from another distro or from a user using quantal , it won't work :)
[15:07] <sil2100> rperier: might be a good first patch ;)
[15:07] <rperier> :)
[15:08] <sil2100> lp:unity is to be supported for building on raring anyway - we like it to build on one older version too, but the rule is that we *should* only really care about quantal in the lp:unity/6.0 branch
[15:08] <sil2100> But anyway, rperier prepare a branch, a merge request and let's get your first (?) patch rewieved and discussed ;)
[15:15] <sil2100> Trevinho: could you re-merge https://code.launchpad.net/~3v1n0/unity/launchers-resize-new/+merge/135816 ?
[15:35] <bregma> rperier, we'd welcome a patch to fix that
[15:36] <sil2100> rperier: and it's a good way to familiarize directly with how to contribute to unity through launchpad
[15:36] <rperier> I will write a patch this evening in the train ;)
[15:41] <bregma> rperier, we'll look forward to your merge proposal
[15:41] <sil2100> :)
[15:41] <rperier> thanks
[15:42] <sil2100> mterry: I fired up a new autopilot test of indicators and 2 failures again, some of those that we already know of
[15:43] <sil2100> Trying to do something about them, adding more sanity checks - but still not sure what's going on
[15:43] <mterry> sil2100, build 82?
[15:43] <rperier> for the beginning, I will look at FTBFS and SEGFAULT I think, and then I will increase difficulty
[15:44] <sil2100> mterry: yes
[15:44] <sil2100> mterry: can you try your magic to get any of those reproduced ;) ?
[15:44] <mterry> sil2100, :)
[15:45] <sil2100> rperier: ok, slowly but surely - start off from some small things, get to know the process, then you can take on something more complicated
[15:45] <mterry> sil2100, I feel like some idiot cousin.  "Go send Mike out there, he's sure to fuck something up"
[15:45] <mterry> "Disaster follows him everywhere"
[15:45] <sil2100> mterry: hehehe, nooo! It's not like that!
[15:45] <mterry> :)
[15:51] <mterry> sil2100, no, can't reproduce
[15:53]  * sil2100 is shocked
[15:53] <sil2100> :o
[15:53] <sil2100> ;) Thanks!
[16:49] <rperier> sil2100: this is exactly what I had in mind :)  (and this is the right way to start on a new project)
[16:49] <rperier> ;)
[17:01] <rperier> branch pushed on my LP account ;)
[17:09] <rye> hi, is unity dash supposed to be full screen/regular size or it should be possible to maximize it / restore? A while ago it was maximized only and the minimize button did nothing (just closed the dash). Now it is of a standard size and maximize button does nothing
[17:17] <sil2100> rye: since when did you notice this problem? Since I'm using week-old staging unity and everything seems fine here
[17:18] <sil2100> rye: since the maximize/restore buttons should work as for normal windows, i.e. maximize and restore
[17:19] <rye> sil2100: today - for unity being always "Restored", and I guess 4 days already for it being always maximized (but I failed to tell about this). I am using latest and greatest unity-team/staging on raring
[17:19] <sil2100> rye: might be a nasty regression - I'll try upgrading and checking that as well
[17:19] <rye> for dash being always "Restored"
[17:20] <sil2100> rye: in the meantime, you might anyway fill in a bug - paste the bug link here so I can 'confirm it' if anything
[17:20] <rye> sil2100: hmmmmm, i found the sensitive area for the button - it's starting from the left border till the image of the square
[17:21] <sil2100> Oh, hm
[17:21] <sil2100> Is the dash looking differently than before?
[17:21] <rye> sil2100: define: differently
[17:21] <bregma> actually, it looks like the button pres is getting sent in behind
[17:22] <bregma> I clicked on the min/max button on the dash and it made the (maximized) terminal in behind go back to non-maximized state
[17:22] <bregma> but didn;t affect the dash
[17:22] <bregma> soudns like a definite bug to me
[17:23] <rye> bregma: nope, does not work this way for me, if i click at the square or to the left/up/down of the square image of maximize/restore button - the dash simply closes
[17:23] <bregma> oh, now it's not doing it for me, either
[17:23] <rye> ok, filing-a-bug
[17:23] <bregma> I guess I clicked twice, and first one closed the dash
[17:24] <bregma> either way, it's a bug
[17:24] <rye> bregma: is it restoring/maximizing if you click slightly to the left on that maximize/restore button?
[17:24] <bregma> yep
[17:24]  * rye is running libc 2.17 and it already broke ubuntuone-syncdaemon's metadata so just to make sure it's not a weird error there...
[17:24] <rye> bregma: great!
[17:30] <rye> sil2100: https://bugs.launchpad.net/unity/+bug/1101310
[17:30] <sil2100> rye: thanks
[18:46] <mhall119> can somebody take a look at https://bugs.launchpad.net/ubuntu/+source/dee/+bug/1096708 and see if we can backport a fix?