[00:18] <bschaefer> fginther, ping
[02:47] <fginther> bschaefer, pong?
[02:47] <bschaefer> fginther, hey, its late for you! Umm I was running into jenkins failing to merge nux branches
[02:47]  * bschaefer goes to dig up the error
[02:48] <bschaefer> fginther, https://code.launchpad.net/~nick-dedekind/nux/remove-animation-on-tick/+merge/136069
[02:48] <bschaefer> it doesn't seem like its the branches fault...
[02:49] <bschaefer> fginther, looks like a lib is not being found
[02:50] <fginther> bschaefer, I'll take a quick look
[02:50] <bschaefer> fginther, thank you, I could poke martin when he gets on
[02:51] <fginther> bschaefer, I enable code-coverage collection on this job, I might have missed something when I did so
[02:52] <bschaefer> fginther, hm interesting, as it worked locally
[02:58] <fginther> bschaefer, It's my fault. I used the wrong hook script to collect the test data. I've updated the jenkins job and re-approved the MP
[02:58] <bschaefer> fginther, alright, thanks!
[02:59] <fginther> bschaefer, https://code.launchpad.net/~smspillaz/nux/nux.fix_1086701/+merge/138070 will also fail for the same reason.
[02:59] <fginther> I'll kill the job and restart it
[02:59] <bschaefer> alright, I could have also waited :)
[02:59] <bschaefer> and re-did
[02:59] <bschaefer> re-approve it
[03:03] <fginther> bschaefer, they should be good now, but I'll check in on them later to make sure
[03:04] <bschaefer> fginther, thank you! Ill try to keep an eye out as well
[09:06] <didrocks> mmrazik: https://jenkins.qa.ubuntu.com/job/unico-autolanding/build=pbuilder,distribution=coverity-raring,flavor=amd64/2/console seems an internal builder issue?
[11:40] <didrocks> hey sil2100
[11:40] <didrocks> sil2100: did you see that unity is FTBFS on armhf?
[11:40] <didrocks> bregma: FYI ^
[11:40] <didrocks> not sure if it's an archive mismatch or intended
[11:40] <didrocks> like the -dev package not being published right
[11:41] <didrocks> will worth a shot looking at it/launching a rebuild if you can :)
[11:43] <sil2100> didrocks: for armhf?
[11:43] <sil2100> Og
[11:43] <sil2100> Oh
[11:43] <didrocks> yep yep :)
[11:43] <didrocks> possible it's just a publisher skew
[11:43] <didrocks> but worth confirming :)
[11:43] <sil2100> Didn't see that one, thanks for pointing out - I was just looking at the armel failure from earlier
[11:44] <sil2100> But I saw an issue like that before, and it might really be just a publisher problem
[11:44] <didrocks> just relaunch a build manually once nux armfh is published
[11:45] <didrocks> the closer we are to a possible faulty rev, the better :)
[11:54] <MCR1> smspillaz: Hi. Bad news. I think Compiz r3512 broke window selection quite heavily... Sometimes you can click through windows on the desktop now, docks like Docky, Plank or glx-dock are not able to restore minimized windows anymore - Are you running Compiz trunk ?
[11:56] <MCR1> @all: Can anyone confirm this regression ^^ ?
[11:56] <smspillaz> MCR1: not at the moment
[11:57] <smspillaz> MCR1: you sure it was 3512 ?
[11:58] <smspillaz> MCR1: 3512 didn't touch the shape code
[11:58] <MCR1> smspillaz: No, I am not 100% sure that it was r3512...
[11:58] <smspillaz> MCR1: more likely would be 3513
[11:59] <MCR1> smspillaz: Maybe r3513...
[11:59] <smspillaz> MCR1: though, I wouldn't say "3513 broke it"
[11:59] <MCR1> yes
[11:59] <smspillaz> more likely is that 3513 is triggering a bug that was already there
[11:59] <MCR1> I just know that working with windows and Compiz is quite complicated at the moment
[11:59] <seb128> andyrock, ^
[12:00] <smspillaz> MCR1: I'm a bit busy atm, but you can debug this yourself - check with xwininfo -all (and xwininfo -id (the parent window)) to make sure that the right window shape is applied up the chain
[12:00] <smspillaz> seb128: leave andyrock alone :)
[12:01] <seb128> smspillaz, he /query me 15 min ago asking if I was running compiz trunk and if I had issues that look like the one MCR1 is describing, he was looking for confirmation of whether there is a bug or if he has a local issue
[12:01] <smspillaz> seb128: coolio :)
[12:01] <seb128> ;-)
[12:01] <MCR1> The most easy way to reproduce the problem is to install any Dock and try to minimize/restore windows with it...
[12:01] <seb128> smspillaz, hey btw, how are you? ;-)
[12:01] <smspillaz> mmmm okay
[12:02] <smspillaz> I haven't been able to get that startup thing I was meant to be doing off the ground
[12:02] <smspillaz> probably procrastinating it
[12:02]  * smspillaz should probably get on to that
[12:03] <smspillaz> seb128: how about yourself ?
[12:03] <seb128> smspillaz, I'm good thanks ;-)
[12:03] <MCR1> smspillaz: I would not nerve you, but this seems quite serious as it makes working with windows hard (sometimes you click through them or they become fully unresponsive)
[12:03] <andyrock> seb128, smspillaz what's up?
[12:04] <seb128> andyrock, I though the issue from MCR1 was similar to yours
[12:04] <seb128> you were looking for confirmation
[12:04] <smspillaz> MCR1: patience :)
[12:04] <smspillaz> we are mere mortals
[12:05] <MCR1> I do not like to bring the bad news, but I think it is better to identify such problems fast, until they get lost in the timespace and will be harder to find many revisions later...
[12:06] <smspillaz> MCR1: of course, what I'm saying is, we'll get on to it soon
[12:06] <smspillaz> but not right now
[12:07] <MCR1> ok - you have been informed about the problem now ;)... thanks in advance
[12:09] <andyrock> MCR1, [Fatal 13:09:00.015] DBus could not be found and is required by Docky. Exiting.
[12:10] <MCR1> oh strange, Docky works here - but I got it from the ppa, maybe the version in the repo is not up-to-date
[12:11] <MCR1> andyrock: docky-core/ppa
[12:12] <MCR1> andyrock: You can also use any other dock, like cairo-dock or plank to reproduce
[12:13] <andyrock> i'm installing docky ppa
[12:13] <andyrock> still get that issue
[12:15] <MCR1> andyrock: It seems to be Compiz r3513 causing the problem...
[12:15] <MCR1> andyrock: btw, thanks 4 fixing the Place issue...
[12:16] <MCR1> andyrock: I got it working here by changing the load order - Do all the Place plugin settings work now ? Like open window where the mousepointer is ?
[12:17] <smspillaz> I wonder if the unity plugin is forwarding the ::place wrap function call
[12:17]  * MCR1 is also wondering...
[12:18] <andyrock> smspillaz, yes if the window was not maximized
[12:18] <smspillaz> ... is that intentional ?
[12:18] <smspillaz> because that's almost certainly broken behaviour
[12:18] <andyrock> smspillaz, for what I see yes
[12:18] <smspillaz> andyrock: can we see if it would be possible for forward the call ?
[12:19] <smspillaz> the place plugins has lots of logic to ensure that windows end up in the right place, skipping it for all restored windows surely doesn't make any sense
[12:19] <smspillaz> andyrock: or was it for maximized window sthat we skip it
[12:20] <andyrock> i need to study unity history to see why it does not forward the call if the window was maximized
[12:20] <smspillaz> ah
[12:20] <smspillaz> it makes sense if it doesn't forward the call when the window is maximized
[12:21] <MCR1> I just know that all different Place-plugin settings work perfectly if it is started after unityshell, so the fix should make all options in the Pace plugin fully functional...
[12:21] <smspillaz> (eg, automaximization logic)
[12:21] <smspillaz> MCR1: indeed, loading if after unityshell will cause the place logic to be called first
[12:21] <smspillaz> however, I'd like to make sure that we don't load plugins after unityshell
[12:21] <MCR1> yes, I know...
[12:21] <MCR1> ;)
[12:21] <smspillaz> having it at the end means we can make certain assumptions
[12:24] <andyrock> MCR1, btw if you can still reprdouce the bug using compiz trunk (loading unityshell after the place plugin) ping me
[12:26] <MCR1> andyrock: ok, I will restore original load order, test the new fix and report soonish...
[12:27] <andyrock> danke
[12:27] <MCR1> bitte
[12:29] <smspillaz> heh
[12:29] <smspillaz> "thanks please" is not often a phrase I hear used in english that much :)
[12:35] <MCR1> smspillaz, it can be even better - like dankeschön, bitteschön - which would mean thanksbeautiful, pleasebeautiful...
[12:36] <smspillaz> einshuldegen sie!
[12:36] <smspillaz> (that is, about the extent of my german)
[12:37] <MCR1> hehe
[13:06] <Zhenech>  /wi3
[13:09] <didrocks> sil2100: compiz is FTBFS as well, can you look at what's wrong? (eventually reverting if we cant' find the fix)
[13:13] <sil2100> didrocks: ACK!
[13:13] <didrocks> thanks :)
[13:27] <sil2100> didrocks: the problem is not in compiz sadly
[13:27] <sil2100> didrocks: it seems python2.7-minimal version 2.7.3-11ubuntu1 in raring is broken ;/
[13:27] <sil2100> didrocks: or maybe something changed organization-wise maybe
[13:28] <sil2100> didrocks: i.e. in the past python2.7-minimal was supposed to provide the pyconfig.h file, but version 2.7.3-11ubuntu1 doesn't provide it - although 2.7.3-5ubuntu5 still does, but the -11 one not
[13:28] <didrocks> sil2100: do you have time to investigate a little bit? indeed, there has been an new python2.7 yesterday
[13:28] <didrocks> sil2100: like pinging doko about I?
[13:28] <didrocks> it?
[13:28] <sil2100> didrocks: ok, I'll dig further
[13:28] <sil2100> Maybe they moved it into another package
[13:29] <didrocks> sil2100: there is a long changelog to look at :)
[13:29] <didrocks> thanks again sil2100 :)
[13:30] <sil2100> ;) Looking and pinging
[13:32] <sil2100> np!
[14:07] <katie> ivanka: https://plus.google.com/hangouts/_/812365a2aeff04c3d674ae01b47a680dd6d0090f?authuser=0&hl=en#
[14:43] <sil2100> didrocks: ok, so, doko doesn't seem to be around to answer my questions, but from what I saw, the latest changes he made simply removed the pyconfig.h installation rules from debian/rules - and didn't really re-add/re-enable it anywhere else
[14:43] <didrocks> sil2100: that's weird, he just uploaded a gcc though
[14:43] <sil2100> didrocks: pyconfig.h is generated, but not installed
[14:44] <didrocks> interesting
[14:44] <didrocks> nothing in the changelog for that?
[14:44] <sil2100> didrocks: so I would guess it's a packaging error on Ubuntu side - but to be sure I would have to poke doko
[14:44] <sil2100> Nothing
[14:44] <sil2100> http://bazaar.launchpad.net/~doko/python/pkg2.7-debian/revision/93
[14:44] <sil2100> Here is the revision that removed the installation in debian/rules
[14:44] <sil2100> I poked him on the channel and priv, so I guess he would answer if he was around
[14:45] <didrocks> sil2100: I'm poking barry right now
[14:46] <sil2100> didrocks: thanks! I'm guessing this got removed by accident during the debian/rules cleanup
[14:46] <sil2100> Since I'm pretty sure that pyconfig.h is still as important as it was
[14:46] <didrocks> yeah, possibly, I'll let you answering once barry is around :)
[14:46] <didrocks> thanks for digging in!
[16:47] <didrocks> sil2100: excellent work again! :)
[16:48] <sil2100> didrocks: thanks :)!
[16:49] <didrocks> sil2100: can you track that until the python fix is landing?
[16:49] <didrocks> (maybe pinging people again if not by tomorrow morning ;))
[16:51] <sil2100> didrocks: ACK - but as doko said, the python problem is a typo, so it should be fixed soon I hope!
[16:51] <didrocks> hoping so :)
[17:43] <bobweaver> Hello there anyone know where quicklinks are rendered in unity 2d ?
[17:43] <bobweaver> I am have troubles with anchors
[17:44] <bobweaver> I will take screenshot
[17:46] <bobweaver> http://imagebin.org/238933
[17:47] <bobweaver> I tried looking under shell/launcher/Launcher.qml and well all the all the rest I fixed the pips because they where off also but I was able to find that
[17:48] <bobweaver> but I can not find the anchors.{what.ever } for quicklists