[07:33] <didrocks> mmrazik: hey, in case you didn't see my comment: https://code.launchpad.net/~ps-jenkins/window-mocker/latestsnapshot/+merge/147433
[07:46] <mmrazik> didrocks: didn't see it. In the last week or so I've seen several branches not being marked as merged by launchpad
[07:47] <mmrazik> didrocks: its launchpad who is changing the state, right? Not the bot...
[07:47] <mmrazik> seen it 4-5 times or so last week
[07:47] <didrocks> mmrazik: oh, right, it's LP, Friday evening mind's screwup :)
[07:47] <mmrazik> didrocks: but it is weird that the diff was generated empty
[07:47] <didrocks> mmrazik: so a trigger in LP didn't work I guess
[07:47] <didrocks> mmrazik: the diff is generated everytime trunk changes
[07:47] <mmrazik> didrocks: that was my assumption, yes
[07:47] <mmrazik> didrocks: I don't think that is true
[07:48] <mmrazik> or at least I've never seen a diff to change once it is generated
[07:48] <mmrazik> only if the candidate branch changes
[07:48] <didrocks> mmrazik: same, I don't have the real rule, but I've definitively see new conflicts generated sometimes
[07:48] <didrocks> without the candidate branch changes
[07:48] <mmrazik> magic...
[07:48] <didrocks> it's a little bit of black magic for me
[07:48] <didrocks> yep :)
[07:48] <mmrazik> :)
[07:56] <didrocks> Mirv: hey, did you see that seb added some more infos on your Qt branches?
[07:57] <didrocks> Mirv: and some were rejected, can you please before we do our hangout ensuring that all licenses reflect the files in the project?
[07:59] <Mirv> didrocks: hi. actually I haven't noticed that.
[08:00] <Mirv> didrocks: licenses need to be re-checked module by module, but at least regarding the added license files all modules have code that fall under those
[08:01] <didrocks> Mirv: apparently not from what seb is telling, I didn't check TBH
[08:01] <Mirv> didrocks: where is that info?
[08:02] <Mirv> oh, a new column in the doc..
[08:02] <Mirv> too far on the right
[08:02] <didrocks> Mirv: yep, "New review comments"
[08:02] <Mirv> ok then
[08:02] <didrocks> Mirv: do you mind having a look for all project before we resume the hangout?
[08:02] <didrocks> just ping me once you are ready :)
[08:03] <Mirv> didrocks: ok
[08:03] <didrocks> thanks!
[08:09] <jibel> any idea why on a default install, compiz would load the font 'Nanum Gothic' (along with more standard ones)? This alone consumes 400kB of memory.
[08:11] <didrocks> jibel: I saw you g+ post, I think it's Nux, let me check
[08:12] <jibel> I couldn't figure why with fontconfig in debug mode
[08:12] <didrocks> hum, didn't find it straight away, looking quickly over nux/compiz/unity code, but I'm sure Nux is doing some stuff with fonts (or at least, did in the past)
[08:12] <didrocks> so I wouldn't be surprised if this is the root cause
[08:16] <jibel> yeah but it is really not trivial to find because there are lot of criteria involved in font matching
[08:17] <didrocks> indeed
[08:43] <Mirv> didrocks: ok we could have something now
[08:43] <didrocks> Mirv: great, coming :)
[10:59] <popey> JohnLea: when you initiate spread in raring, the windows which get zoomed out all get resized down by a small factor, and then resized back up again when you come out of spread. Is this intentional? It causes redraws of the applications being spread, unncessarily so IMO.
[10:59] <JohnLea> popey: let me test, and I will get back to you
[10:59] <JohnLea> thanks for the heads up
[11:02] <popey> JohnLea: see http://popey.com/~alan/max.png and http://popey.com/~alan/spread.png for an example. the VirtualBox application window gets resized ~28px smaller causing a full desktop redraw in the vm.
[11:03] <JohnLea> popey; yes, that sounds to me like a bug, the spread should be scaling (not resizing) the windows.
[11:04] <popey> ok, I'll file it
[11:04] <JohnLea> popey; thanks!  I'd also recommend asking smspillaz about it
[11:04] <popey> roger
[11:04] <JohnLea> popey; ping me the bug # when done, thx!
[11:05] <popey> roger roger
[11:05] <andyrock> popey, JohnLea The spred does scale the windows
[11:06] <JohnLea> andyrock; so that is desired behaviour?
[11:06] <andyrock> JohnLea, no I think the problem here is the decoration
[11:10] <andyrock> JohnLea, but the right guy to talk about it is Trevinho here
[11:10] <JohnLea> popey; ^
[11:10] <JohnLea> andyrock; thx
[11:11] <andyrock> btw let me check the code
[11:13] <popey> andyrock: JohnLea bug 1121941
[11:13] <andyrock> popey, it happens just for maximized windows, right?
[11:14] <popey> good question
[11:14]  * popey tries
[11:14] <andyrock> popey, thx
[11:15] <popey> andyrock: yes, maximised windows only
[11:15]  * popey edits title of bug
[11:16] <andyrock> popey, http://paste.ubuntu.com/1636066/
[11:16] <andyrock> line 9-10
[11:16] <andyrock> i think these lines trigger the issue
[11:17] <andyrock> but IIRC we draw a fake decoration for maximized windows in the spread
[11:18] <andyrock> so it should not be needed
[11:18] <andyrock> but let's wait Trevinho
[11:20] <andyrock> this could explain also bug https://bugs.launchpad.net/compiz/+bug/1039942
[11:20] <smspillaz> andyrock: if WindowManager::Decorate sets MWM_DECOR in _MWM_HINTS then compiz will re-decorate and resize the window
[11:20] <smspillaz> I don't think its related to 1039942 though
[11:38] <andyrock> popey, ok I've a branch that fixes the issue
[11:39] <andyrock> i just need to do some more tests with special app/window (chrom*, etc)
[11:44] <sil2100> :)
[11:49] <sil2100> didrocks: hi! A thing related to the search-testing as part of libcolumbus... maybe for now we could merge the AP test code even now? I would just comment out the app lens fuzzy tests, as those are failing without columbus
[11:49] <didrocks> sil2100: sounds good to me then :)
[11:49] <sil2100> didrocks: this way we would have some time to test the search code a bit
[11:49] <sil2100> In a real testing environment
[11:50] <didrocks> sil2100: yep, please do not hesitate :-)
[11:50] <sil2100> didrocks: ok :)
[12:14] <sil2100> didrocks: hm, do you know if the Window Mocker name will be translated into many languages?
[12:15] <didrocks> sil2100: we shouldn't up until we need it for other tests
[12:15] <didrocks> that's IMHO :)
[12:15] <didrocks> at worse, we can have 2 desktop files
[12:15] <didrocks> one translated and launching the app
[12:15] <didrocks> and another one untranslated and shipping with LANG=C
[12:21] <sil2100> For me it would be better if we didn't for now as well
[12:33] <Trevinho> popey, JohnLea, andyrock: it happens because we have to re-decorate a maximized window in order to be able to draw on it its decoration...
[12:34] <Trevinho> popey: this was needed for the scale, however due to some changes I did recently for the alt+tab spread, I think we can avoid this... But I need to look further at it
[12:41] <smspillaz> heh, I remember when I did the same thing about two years ago now and ran into the same problem :p
[12:41] <smspillaz> the solution of course being just drawing the decoration pixmap, but we have the ability to do that now
[14:39] <mterry> didrocks, you said in your email that UTAH is fixed?  We made some progress?
[14:40] <didrocks> mterry: hey, the local.rc fix is supposed to land soon
[14:40] <didrocks> mterry: but anyway, with the power outage, we can't really know yet :)
[14:42] <mterry> didrocks, local.rc?  I may have missed a conversation
[14:43] <didrocks> mterry: they were two known issues for provisionning an image, one is bug #1118581
[14:43] <didrocks> mterry: the other (the Friday evening one) was a file conflict in the default packages
[14:43] <didrocks> aborting the install
[14:43] <mterry> right
[14:44] <didrocks> both are fixed
[14:44] <didrocks> now, we need to wait for the QA lab to be up again
[14:44] <didrocks> well, the magners machine rather
[14:44] <didrocks> (the rest is up)
[14:44] <mterry> Yup.  OK
[14:44] <mterry> didrocks, have a good weekend?
[14:45] <didrocks> mterry: was nice, quite some snow here as well, so didn't do anything too exciting ;-) yourself?
[14:47] <mterry> didrocks, just stayed inside through most of our snowstorm.  Thankfully I don't have a car, so was quite happy watching everyone else digging out their cars
[14:49] <didrocks> mterry: yeah, it's the time as well I enjoy to only rent a car when I'm needing it :)
[15:16] <mterry> didrocks, what do you use to make snapshot packages of the various unity upstreams?
[15:16] <didrocks> mterry: do you talk about the upstream tarball?
[15:17] <mterry> didrocks, yeah
[15:19] <didrocks> mterry: so, I'm using the split mode of bazar to do that. This is down in a cowbuilder chroot, where I sign the source package (after installing the build-deps)
[15:20] <didrocks> mterry: look at the chroot-tools/ directory, containing the .pbuilderrc and buildsource-chroot tool
[15:22] <mterry> thanks
[16:09] <didrocks> mterry: oh, I would have 2 MIRs for you to look at if possible
[16:10] <didrocks> mterry: qt5chooser, I'll ask Mirv_ to give the rationale soon (it's needed for coinstalling Qt4 & 5 on the same machine for a dev env, but he knows more than I)
[16:11] <didrocks> mterry: for libcolumbus, I think we can prepare things a little bit before, wdyt? cyphermox, do you mind prepping a MIR for it? (Satoris is upstream)
[16:13] <mterry> didrocks, k
[16:13] <didrocks> thanks mterry :)
[16:13] <mterry> didrocks, cyphermox : poke me with bugs when you have them
[16:13]  * didrocks goes back to Qt5 and headaches
[16:15] <cyphermox> ok!
[16:17] <didrocks> thanks cyphermox ;)
[16:23]  * davmor2 hands didrocks some paracetamol there now it's just qt5
[16:23] <didrocks> davmor2: thanks, would be a big help :)
[16:35] <Mirv> mterry: qtchooser is the upstream recommended and Debian adopted tool to co-install dev executables of Qt4 and Qt5, so needed now for libqt4-dev and developing with Qt5. it replaces the manually patching to add suffixes and alternatives system used earlier.
[16:37] <mterry> Mirv, sure
[16:42] <mterry> Mirv, is there a bug for its MIR yet?
[16:43] <mterry> Mirv, didrocks said qt5chooser.   But you say qtchooser.  Which package name is it?  I notice that qtchooser is already in main
[16:43] <didrocks> mterry: sorry, was qtchooser
[16:44] <mterry> didrocks, it's in main now it looks like.  Is this an after-the-fact mir?
[16:47] <didrocks> mterry: yeah, sorry, didn't give you context :)
[16:47] <didrocks> mterry: it's based on the upload of qt4-x11 we did Friday
[16:48] <didrocks> and yeah, after-the-fact MIR
[16:48] <cyphermox> didrocks: mterry: who will upload li
[16:48] <cyphermox> *libcolumbus
[16:48] <cyphermox> like, ETA for the upload?
[16:49] <mterry> didrocks, but no bug yet?  Can you or Mirv file a bug and I'll start looking
[16:49] <mterry> cyphermox, don't know
[16:49] <didrocks> cyphermox: this week? with daily release
[16:49] <cyphermox> ok
[16:49] <didrocks> mterry: that's why I ask Mirv to give you the info, to get a bug :)
[16:50] <didrocks> cyphermox: it's needed prior the new hud
[16:50] <didrocks> so tomorrow if jenkins is back :)
[16:50] <cyphermox> hud is what b-deps on it right?
[16:50] <didrocks> cyphermox: yeah, or is already, look at the MP :)
[16:51] <didrocks> sorry, still on Qt5 and really really needs paracetamol I guess…
[16:51] <mterry> Mirv, can you please file a MIR bug with the info you gave me  on IRC?  https://wiki.ubuntu.com/MainInclusionProcess
[17:06] <cyphermox> mterry: are doing any other MIRs currently?
[17:06] <cyphermox> libcolumbus also needs libsparsehash-dev; I'll write the mir now unless you're already working on it
[17:07] <mterry> cyphermox, I'm not working on it.  Please write it up
[17:07] <mterry> I'll review once written
[17:07] <cyphermox> ack
[17:10] <davmor2> hey guys why does quantal look like this http://ubuntuone.com/6eZ84ok0EYTNWcGWOVzoCG and raring look like this http://ubuntuone.com/52xxNl1j5swOuyDo7SNWUa
[17:13] <bregma> davmor2, can you be more specific about which difference you're referring to, and what you're expecting?
[17:14] <davmor2> bregma: I'm expecting them to look the same they are the same track the only difference is the distro series
[17:15] <davmor2> the size of the dash is irrelevant
[17:16] <mterry> davmor2, looks like the only difference is the cover art?
[17:16] <mterry> davmor2, the banding on top and bottom is expected
[17:16] <davmor2> mterry: album name
[17:16] <mterry> I guess one has left arrow and other has right arrow.  I don't know if that is expected
[17:16] <bregma> davmor2, I see you have the dash configured in full-screen mode in your raring example, and the album cover art is missing, and the raring example is using the new raring assets instead of the quantal assets, but it would be good to know more clearly what you're expecting
[17:17] <mterry> davmor2, album name looks the same to me.  "Running Up That Hill" in both
[17:18] <davmor2> mterry: oh yes sorry I was seeing the title on the image my fault
[17:19] <bregma> question is, why is the album art missing?
[17:21] <davmor2> bregma: that's the big question
[17:21] <davmor2> I'm just checking through by all accounts there is no album art displayed for any track
[17:22] <bregma> all I can suggest is that the dash and scopes are going through some significant development at the moment, and that there may be an impledence mismatch somewhere i the stack that will get irond out in time
[17:23] <davmor2> bregma: and the full screen is a default this is a vanilla install for testing
[17:24] <bregma> I just searched for that album with today's raring build and got the cover art in the preview
[17:25] <davidcalle> davmor2, bregma: regarding album art. With Rhythmbox as the default, we depend on it for album art, it needs to be closed at least once to list the album art it has feched in its db, then the lens can pick it up.
[17:25] <davidcalle> s/list/add
[17:28] <davmor2> davidcalle: Nope also oddly if RB is closed and I click on a track it isn't played it just opens the player
[17:29] <davidcalle> davmor2, interesting :/
[18:07] <cyphermox> mterry: https://bugs.launchpad.net/ubuntu/+source/sparsehash/+bug/1122265
[18:08] <cyphermox> mterry: https://bugs.launchpad.net/ubuntu/+bug/1122269
[18:09] <cyphermox> libcolumbus isn't in the archive yet so I can't match it to the package yet
[18:09] <mterry> k
[18:17] <sil2100> \o/
[18:29] <smspillaz> sil2100: can I modify the "unity" shellscript to not kill compiz when it runs "--replace"
[18:29] <smspillaz> shellscript/python file/whatever
[18:30] <smspillaz> its a hack that just causes problems, and the reason for it existing isn't there anymore.
[18:46] <sil2100> smspillaz: oh, so it's not needed anymore?
[18:46] <sil2100> smspillaz: in this case, I think we can just remove it
[18:47] <sil2100> Trevinho: hi! Are you around?
[18:49] <sil2100> See you later everyone
[19:04] <mterry> fginther, without the staging PPA, if I want to try to reproduce crashes that jenkins is seeing or whatever, how do I use the same packages as Jenkins?
[19:05] <fginther> mterry, jenkins uses an http archive for the packages it builds.
[19:05] <mterry> fginther, an archive that I could point to, I assume?
[19:05] <fginther> mterry, it's possible to use that instead as long as the test system has VPN access (I've done this)
[19:06] <mterry> fginther, OK, cool.  Then I don't mind staging going away
[19:06] <fginther> mterry, the packages are not archived anywhere, so if you needed a specific package that was not the latest, you would be out of luck (which I think is the way the PPA works as well)
[19:06] <mterry> true
[19:11] <mterry> oh hey, jenkins is back up
[19:12] <mterry> cyphermox, do you know if you think the indicator stack will build cleanly now/
[19:12] <mterry> ?
[19:13] <mterry> hmm, the autopilot ati/intel/nvidia machines are still offline though
[19:22] <cyphermox> mterry: I think so
[19:22] <cyphermox> but yeah, depends on the machines being up ;)