[07:54] <mmrazik> didrocks: morning
[07:54] <didrocks> hey mmrazik
[07:54] <mmrazik> didrocks: the unity-team staging PPA seems to be in shape for raring
[07:54] <mmrazik> didrocks: and we (sort of) achieve the same fail rate as on quantal
[07:55] <mmrazik> http://10.97.0.1:8080/view/autopilot/job/ps-unity-autopilot-raring/17/testReport/
[07:55] <mmrazik> didrocks: the issue on intel is that we added a second monitor which retrospectively wasn't a great idea
[07:55] <mmrazik> didrocks: we first need to try that somewhere else
[07:56] <mmrazik> didrocks: I'll ask somebody in Lexington to disconnect it today
[07:56] <didrocks> mmrazik: ah ok, so we can count on ~20/25 failures for real?
[07:56] <didrocks> mmrazik: ack on trying that somehwere else :)
[07:56] <didrocks> ok, so I guess we are rather in a good shape to have that wired this week
[07:56] <mmrazik> didrocks: I would hope so. The only difference is the 2nd monitor. Even the number of executed tests on Intel is much higher (>100 tests)
[07:57] <mmrazik> didrocks: I'm looking into the nvidia box. For some reason autopilot didn't even start there.
[07:57] <didrocks> mmrazik: yeah, it seems to be the latest blocker
[07:57] <didrocks> mmrazik: thanks for the update :)
[09:23] <dholbach> hiya
[09:23] <dholbach> when is a new nux release upload planned for raring?
[09:24] <didrocks> hey dholbach, when autopilot tests are stable enough on all archs to have daily landing
[09:24] <dholbach> ah, ok
[09:25] <dholbach> https://code.launchpad.net/~unity-team/nux/nux.depth-texture-detection-support/+merge/134729 was for the nexus7 bug, right?
[09:25] <dholbach> I just realised that it's still 'needs review'
[09:29] <dholbach> it'd be great to get the MP reviewed and landed
[09:29] <dholbach> as it's blocking things on the nexus7
[09:29] <sil2100> dholbach: it's still being tested, this branch
[09:30] <sil2100> dholbach: currently it diverged from trunk anyway, so I think Jay needs to re-merge it with lp:nux
[09:30] <dholbach> go go go go go! :)
[09:30] <sil2100> dholbach: since anyway it cannot be approved, as there are text conflicts ;)
[09:32] <sil2100> dholbach: I have no nexus7, but I was able to test-build it on my pandaboard and send the whole re-built unity stack it to people responsible
[09:32] <sil2100> dholbach: so I think we might have it reviewed soon
[09:32] <dholbach> you are heroes
[09:33] <dholbach> if you want anything tested on the nexus7, let me know
[09:38] <mmrazik> didrocks: FYI -- we have a compiz crash on all machines :-/ AFAICS its 1:0.9.8.4+bzr3412-0ubuntu1 or something around bzr3412
[09:38] <mmrazik> https://bugs.launchpad.net/compiz/+bug/1083491
[09:39] <didrocks> mmrazik: ping bregma about it
[09:39] <didrocks> mmrazik: adding to the list, thanks :)
[10:34] <didrocks> Mirv: hey! I don't understand the versionning of the precise bamf. The current one is 0.2.118, and you are releasing 0.2.124, why this jump?
[10:34] <didrocks> Mirv: also it seems that ~ubuntu-desktop/bamf/precise is up to date
[10:34] <didrocks> so can you base on that one?
[10:35] <didrocks> Mirv:     - removed symbols that were wrongly exported upstream before (private
[10:36] <didrocks>       symbols)
[10:36] <didrocks> this is not backportable though
[10:36] <didrocks> (I already removed it when you proposed the previous SRU btw)
[10:36] <didrocks>   * Bump gobject-introspection build-dep to 0.10.2
[10:36] <didrocks> -> this is borderline, I would prefer we don't change it if possible
[11:22] <mhr3>   110 signal com.canonical.indicator.application.service.ApplicationTitleChanged
[11:22] <mhr3>   110 signal com.canonical.indicator.application.service.ApplicationLabelChanged
[11:22] <mhr3>   110 signal com.canonical.indicator.application.service.ApplicationIconChanged
[11:22] <mhr3> larsu, ^ y u spam my dbus? :(
[11:24] <larsu> mhr3, haha, I'm guessing it does that *very* often?
[11:24]  * larsu didn't write that code
[11:26] <Mirv> didrocks: hi! the jump is to catch with upstream fixes instead of just cherry-picking fixes.
[11:26] <mhr3> larsu, the good news is, i see a simple way to send 3 times fewer signals :)
[11:26] <Mirv> didrocks: which means that 0.2 upstream branch should then have the symbol commit reverted - I guess that was done at a time that 0.2 was used for quantal and 0.3 wasn't branched yet
[11:27] <larsu> mhr3, that's exactly what unity.indicator will be doing (well, once I have time to work on that again :( )
[11:27] <mhr3> larsu, wonderful :) then the only thing that's spamming like crazy is bamf
[11:28] <larsu> mhr3, why am I not surprised by that?
[11:28] <larsu> :P
[11:28] <Mirv> didrocks: that's a bit complicated, though, since the other 0.2 backports have been made on top of your commit that removed the symbols
[11:29] <didrocks> Mirv: you can just revert it I guess
[11:29] <didrocks> basically, we don't want to change the symbols
[11:30] <didrocks> Mirv: ok with the version
[11:30] <didrocks> Mirv: or as there are few commits cherry-picks, we can just think about doing distro-patch
[11:30] <mhr3> larsu, everything should just use dee, it's doing good job at minimizing the number of transactions ;)
[11:31] <mhr3> like i just did 140 search requests to lenses and dee emitted a dbus signal 48 times
[11:32] <Mirv> didrocks: I'll wade through the conflicts that come from reverting it, nothing too scary, and do 0.2.124.1 after reverting.
[11:32] <didrocks> Mirv: excellent! thanks a lot, for testing, just be light about it, install and ensure it matches apps :)
[11:32] <larsu> mhr3, nice, I should definitely look into dee once I work on something non-menu related ;)  (for which GMenuModel is excellent btw)
[11:33] <Mirv> didrocks: sure, we'll do some more testing before handing it over again. I'll be back later on.
[11:33] <mhr3> larsu, true glib people do think about these things too.... as opposed to bamf :P
[11:33] <didrocks> Mirv: thanks :)
[13:07] <mvo> Trevinho: hi, how is https://code.launchpad.net/~mvo/unity/sc-launcher-integration-fixes/+merge/134931 look now? any further suggestions :) ?
[13:13] <mmrazik> can somebody have a look: https://code.launchpad.net/~mrazik/unity/coverage-support/+merge/136345
[13:19] <didrocks> mvo: Trevinho will only be around tonight FYI
[13:24] <mvo> thanks didrocks
[13:44] <didrocks> fginther: hey, how are you?
[13:48] <fginther> didrocks, morning
[13:49] <didrocks> fginther: I wanted to know if you've made any progress on the oif stack for autolanding with packaging inline? I saw a reject on one project and nothing else
[13:51] <vibhav> Are there any parts of Unity written in C?
[13:51] <fginther> didrocks, yes, I was able to just get to one yesterday. The rest will be done today
[13:52] <fginther> didrocks, as long as jenkins cooperates :-)
[13:52] <didrocks> fginther: ok (the one from yesterday wasn't merged successfully, isn't it?). So you think you'll get all done today? Nice :) I'll be able to enable the oif stack tomorrow then for autolanding in ubuntu
[13:53] <fginther> didrocks, yes, I don't have anything higher priority at the moment.  The merge from yesterday failed from a missing commit message I believe
[13:53] <didrocks> fginther: yeah, but as you didn't get back to it just to set it, I thought you saw other problem :)
[13:54] <didrocks> fginther: feel free to put "merge packaging inline" in those btw :)
[13:54] <fginther> didrocks, ah ok, I can do that for the remainder if necessary.
[13:54] <didrocks> fginther: that would be excellent, thanks :)
[13:54] <fginther> didrocks, yw
[14:12] <didrocks> pstolowski: hey, do you need help with you MP?
[14:12] <didrocks> your*
[14:12] <didrocks> for the symbol files
[14:14] <pstolowski> didrocks: hey, no, I should manage this, did it before for another MP. but thanks for asking!
[14:14] <didrocks> pstolowski: just ensure that the version is 0replaceme that you set
[14:14] <didrocks> in case you don't know that yet :)
[14:15] <pstolowski> didrocks: yep, I know :)
[14:15] <didrocks> \o/
[14:28] <fginther> bregma, would you like the oif project autolanding jobs to dput into ppa:oif-team/oif-daily?
[14:28] <fginther> or any ppa?
[14:28] <bregma> we already have a daily build into that PPA, but shutting that down and instituting an autoland would be swell
[14:29] <fginther> bregma, in that case, I'll enable it.  dput to precise, quantal and raring?
[14:30] <bregma> exactly
[14:31] <fginther> I'll have autolanding jobs for evemu, frame, grail, geis and libgrip.  should I add any others?
[14:42] <bregma> fginther, that's the list
[14:42] <fginther> bregma, thank you
[14:48] <mmrazik> bregma: FYI -- with the latest compiz in staging PPA we are getting segfaults on all 3 (ati/intel/nvidia) machines.
[14:48] <mmrazik> https://bugs.launchpad.net/compiz/+bug/1083491
[14:49] <mmrazik> its probably going to block the unity release
[14:49] <bregma> ooh, ouch
[14:49] <mmrazik> (srry for crappy bug report; chris will update it morning his time; he was reporting it late in the night)
[14:50] <mmrazik> bregma: the autopilot job running few hours ago was fine so we should be able to (roughly) tell the bzr version which introduced it (should be in the attachment in the end)
[14:50] <bregma> *$%&@# animations in unity
[14:50] <bregma> must. kill. slowly.
[14:51] <didrocks> bregma: between that and tests failing, I can +1 your comment :)
[15:02] <bregma> mmrazik, the most recent nux had an ABI change in the animator class, which is where the unity plugin crashes are happinging -- is there possibly a mismatch between the nux binaries and the unx dev package in the PPA build environment?
[15:03] <didrocks> bregma: wasn't the version bumped in nux? for the ABI?
[15:03] <mmrazik> fginther: ^^^
[15:04] <bregma> no version bump (not standard practice) but if the unity plugin is built with a different header than the library binary in the compiz build, there's a broken dependency somewhere along the track
[15:06] <didrocks> bregma: well, they should have bumped the version which prevents and will tell immediately that unity can't be installed without a rebuild :)
[15:06] <bregma> could be a newer nux and older unity or a newer unity and older nux
[15:06]  * fginther looks
[15:06] <didrocks> bregma: where is the ABI break btw? I only see addition, no prototype change or struct size changing? (but as the ABI in C++ is always a mistery… ;))
[15:08] <bregma> two new virtual functions were added to the base class, in the middle of the vtable
[15:08] <bregma> the segfault is on a call to Restart(), which goes off into neverland because its offset within the vtable has changed
[15:08] <didrocks> oh, I missed they are virtual
[15:09] <didrocks> yeah makes sense
[15:09] <didrocks> let's make a MR first for the ABI break
[15:12] <fginther> mmrazik, if there was no version bump, then it's possible the autopilot machines picked up a new nux before the new unity was built (best theory at the moment)
[15:13] <didrocks> fginther: there is never a version bump FYI in nux
[15:13] <mmrazik> fginther: the nux version installed on the system should be in the report. Do we know which one is the right?
[15:13] <didrocks> but at least the virtual package is there to tell you can't install unity and nux that doesn't match
[15:13] <didrocks> (when the right string is changed)
[15:14] <mmrazik> let me try to kick-off a new build then
[15:14] <fginther> mmrazik, that should work, the unity in the ppa is much newer then nux
[15:14] <didrocks> bregma: https://code.launchpad.net/~didrocks/nux/abi-breakage/+merge/136443
[15:15] <mmrazik> fginther, didrocks: the intel box has one monitor now as well.. so lets see
[15:15] <didrocks> mmrazik: ah sweet! real data :)
[15:22] <bobweaver> things that do not launch } unity-standalone (seg fault)  unity-dash (seg fault ) wait this is easy. Every binary there is but build/bin/unity
[15:24] <bobweaver> unity 6.12 ,nux 4.0 ,, compiz  0.9.8.5,libunity-core-6.0.5    6.12.0bzr2934pkg0raring0
[15:25] <bobweaver> which is kinda funny because raring and stagging are getting all mixed up
[15:26] <didrocks> bregma: thanks :)
[15:26] <bobweaver> raring has newer versions of libunity one can not install unity on 13.04 (build that is) with out staging because there is no nux >= 4.0
[15:27] <bobweaver> plugins/unityshell  == broken 100%
[15:27] <bobweaver> cmakelist.txt will not build
[15:27] <bregma> bobweaver, I believe we're working on this as you type
[15:27] <bobweaver> can I help ?
[15:28] <bregma> well, you might have to wait for all the latest things to land in raring, but the staging PPA issue is getting resolved sooner
[15:28] <bregma> mmrazik, do you know when all the current changes will get flushed through into raring-proposed?
[15:29] <bobweaver> I have stagging ppa installed (only place that I could find nux 4.0 for build )
[15:29] <mmrazik> bregma: it probably depends on the results from the jenkins job which is running right now
[15:29] <mmrazik> if it is good then I would assume soon. Like in a few days. Right, didrocks?
[15:29] <bregma> excellent, thanks
[15:29] <didrocks> mmrazik: I can enable that within a day
[15:30] <bregma> bobweaver, do use use jhbuild to build the unity stack, or just the staging PPA?
[15:31] <bobweaver> bregma,  I use cmake  and or qt creator
[15:31] <bobweaver> bzr then  mkdir <source>/build
[15:32] <bobweaver> cd build  then    cmake ../ -DCMAKE_INSTALL_PREFIX:PATH=/<source>/build/      then  make -j4 then sudo make install
[15:33] <bobweaver> I have never used jhbuild
[15:33] <bobweaver> not in wiki looks cool though
[15:34] <bobweaver> I am just a qt/qml / c++ /c / hacker new to unity 3d
[15:34] <bregma> bobweaver, I recommend using https://launchpad.net/unity-jhbuild (which runs cmake for you) because it pulls in and builds all the latest dependencies
[15:35] <bregma> it's a meta-build system
[15:38] <bregma> bobweaver, if you have more questions, feel free to ping me
[15:42] <bobweaver> bregma,  cool and thanks I will give it a shot for sure
[16:00] <bobweaver> bregma,  here is a question about Lensview  I changed it so that ( if renderer_name == "tile-horizontal" ) <then I change to be coverflow for both the if and else> But after build nothing changes  here is file   http://bazaar.launchpad.net/~ubuntu-tv-developers/ubuntutv/trunk/view/head:/dash/LensView.cpp       Lines 329 -- 449
[16:02] <bobweaver> I want to do if render_name = titl.... & formfactor = tv  then ..... But I can not figure out form-factor
[16:04] <didrocks> bregma: http://pad.ubuntu.com/ubuntu-unity
[16:05] <didrocks> bregma: same, just give a quick status before EOW please :) (feel free to comment/ammend directly)
[16:06] <bobweaver> the render thingy in LensView use to work here is a video example :: http://www.youtube.com/watch?v=QcepB1E1lX0&feature=context-gau
[16:07] <bobweaver> I want to kinda set the formfactor of tv to look and act like that but. 1 I can not figure out formfactor in 3d it is not like 2d , and 2 even hardcoding in still dosent work
[16:08] <bobweaver> of course SimpleLauncher(moded lensbar / lensbaricon) and  Slider for filters and also ChannelView also need to be made .......Again :)
[16:12] <bregma> bobweaver, your best bet is to get the standalone tools working first, then it's much much easier to isolate such problems and track down their cause
[16:13] <bobweaver> bregma,   85%] Building CXX object
[16:13] <bobweaver> I need a i7 this thing overheats also
[16:14] <bregma> I had to blow a cloud of dust out of my vent so my computer wouldn;t keep shutting down while building
[16:15] <bobweaver> =)  you have a air compressor ?
[16:15] <bobweaver> << is lucky to have one for working on cars in garage
[16:16] <bobweaver> Also takes about 2X as long because I have "? stacked ?" code meaning dash/ff-tv  ect
[16:17] <bobweaver> I want to work with all you so that we can really get these formfactors Rocking
[16:17] <bobweaver> esp tv and phone
[16:19] <bobweaver> IT IS WORKING !!! Thanks a million bregma  you are awesome !!! I was missing deps
[16:20] <bobweaver> I will add deps to debian/control and push branch ?
[16:32] <bregma> bobweaver, I believe the debian/control file(s) have the correct deps, but they're ignored unless you're building the packages
[16:32] <bregma> and the staging PPAs can be a little out of synch at times as changes work their way through the system
[16:32] <bobweaver> ahh Yeah that is something that I often wonder about build-deps I do not understand it fully
[16:33] <bregma> the only way you can really guarantee stability for developing from trunk is to use jhbuild or manually do the equivalent
[16:33] <didrocks> tedg: thanks!
[16:34] <tedg> Oh, this is still CDBS...
[16:35] <didrocks> tedg: you should turn to dh9, --fail-missing and so on! :-)
[16:35] <didrocks> tedg: the other indicators projects are all on this new trend!
[16:35] <didrocks> again if you need any help, do not hesitate :)
[16:40] <tedg> We should really require every package that needs an override_* to have a bug tracking why they need it.
[16:40] <tedg> Either it's a bug in debhelper or a bug in the project.
[16:40] <didrocks> tedg: TBH, I would be in favor of having --fail-missing by default
[16:40] <didrocks> thoughts on that?
[16:41] <tedg> didrocks, Not sure what it does, which is that one?
[16:41] <didrocks> it's dh_install --fail-missing
[16:41] <didrocks> so, if you forgot to ship a file
[16:41] <didrocks> it will fail
[16:41] <didrocks> you can exclude some files for sure, like .la or .a with -X
[16:42] <didrocks> (all files installed by make installed should be explicitely treated IMHO)
[16:42] <tedg> Uhm, the only case I'd say that'd be tricky is things like gtk-doc where you might not want to have a doc package for internal docs.
[16:42] <tedg> But then you'd have to modify gtk-doc to not install it.
[16:43] <didrocks> right or just --disable-doc… or a switch to not build them
[16:43] <didrocks> I'll enroll you in the cabale then! (what? it doesn't exist ;))
[16:46] <tedg> alesage, Do you want me to hand merge this into trunk?
[16:47] <alesage> tedg, please suffer one more manual merge for me :)
[16:48] <tedg> alesage, Done
[16:49] <mmrazik> didrocks, bregma: seems the staging PPA is ok now: http://10.97.0.1:8080/job/ps-unity-autopilot-raring/label=master,machine_name=dx-autopilot-intel/lastCompletedBuild/testReport/
[16:49] <mmrazik> the nvidia box still has the Xorg crash :-/
[16:49] <didrocks> mmrazik: sweet, with a sane number of failures :)
[16:49] <bregma> the only sane number is zero
[16:49] <didrocks> so only nvidia is remaining has the bad guy now
[16:49] <mmrazik> didrocks: and ati finished as well right now
[16:50] <didrocks> bregma: well, compared to where we started…
[16:50] <bregma> so we are still insane
[16:50] <mmrazik> didrocks: I think he is talking about set theory...
[16:51] <mmrazik> didrocks: I'm quite bad with crash analysis and I'm unable to get any meaningful stack trace out of the Xorg dump
[16:51] <didrocks> bregma: depends, on my previous big/famouse company software, you are never to 0. But yeah, we'll get the number down
[16:51] <didrocks> mmrazik: I can give a hand tomorrow on that if needed
[16:51] <didrocks> famous*
[16:51] <mmrazik> didrocks: if tomorrow is OK then I'll ask veebers to have a look
[16:51] <didrocks> mmrazik: good :)
[16:51] <didrocks> mmrazik: btw, are you only testing with free driver?
[16:52] <didrocks> mmrazik: I think we want the proprieratery one for the tests results, as it's what we support officially AFAIK
[16:52] <mmrazik> didrocks: we only do free AFAICS
[16:52] <didrocks> mmrazik: maybe it's something we need to change, bregma thoughts? ^
[16:52] <mmrazik> didrocks: proprietary instead or in addition to the free?
[16:52] <didrocks> mmrazik: I think instead first
[16:52] <mmrazik> (addition is going to be a bit tricky due to lack of HW)
[16:53] <bregma> ideally we need both
[16:54] <bregma> can we overcome the hardware problem by doing sequential runs?
[16:54] <bregma> or is change turnover too high for that?
[16:55] <didrocks> bregma: I think starting with 1 is acceptable for daily landing, but having on target both is wanted
[16:55] <mmrazik> bregma: we can do sequential runs but it takes ~1.5 per run
[16:55] <mmrazik> 1.5h
[16:56] <bregma> I think we really need both free and non-free since the difference can be substantial, 1.5h isn't too bad for a daily build
[16:57] <mmrazik> Ok. I'll drop veebers an e-mail. He had some issues with installing the proprietary from preseed..
[16:58] <didrocks> fginther: seems evemu is still failing
[16:58] <mmrazik> bregma: not sure if I was clear but its going to be 3 hours if we do sequentially
[16:58] <mmrazik> probably close to 4
[16:59] <bregma> is the hardware used for other builds?
[16:59] <fginther> didrocks, :-) I missed a configuration copy&paste error.  I'm watching the results and will keep trying until it lands
[16:59] <didrocks> great :)
[17:00] <mmrazik> bregma: you mean other projects? Not currently but I need that HW. Its not currently being used just because I really want to release unity and don't want to mess up with the setup.
[17:01] <mmrazik> but 4h is still fine with me
[17:01] <mmrazik> in theory :)
[17:01] <mmrazik> (the issue is that sometimes an installation on the ati box fails for mysterius reasons and if we need to restart after 2 h then the total time will be more like 2+4=6h)
[17:02] <bregma> we really should not land in Ubuntu if it fails on any of free or non-free (for a reasonable definition of fail)
[17:02] <mmrazik> makes sense to me. I'm just saying what the implications might be.
[17:02] <didrocks> yeah, I agree, let's see how deep the configuration is needed, but first, let's have one working at least :p
[17:03] <bregma> yes
[17:04] <mmrazik> didrocks, bregma: I'm just writing an e-mail to Chris to 1. figure out what is the bug# for the current XOrg carsh on nvidia and 2. try to provision the machine with proprietary drivers (and file an utah bug if utah doesn't support this out of the box)
[17:04] <didrocks> mmrazik: thanks a lot! Happy to see we are nearly done :)
[17:44] <didrocks> bregma: I would love enhancing if you give me edit rights on the doc :)
[17:46] <bregma> didrocks, you should have them now, assuming you reload
[17:46] <didrocks> bregma: good assumption :)
[18:03] <bobweaver> I would like to invite all the Unity team members to are Ubuntu TV meeting it is on Friday right before your meeting . It is on the fridge
[18:06] <bobweaver> We need more Unity people in are team. Seems Like I am the only one that is integrating all the old unity 2d code too the Unity 3d. And I am swamped. Could use other developers to come to meeting and get Unity team and Ubuntu TV team on the same page as to where they are going in the future and where things are right now. I for one would like to see a large amount if not all this go together (code). Thanks for considering it. And if yo
[18:06] <bobweaver> u have any question for me about what I am doing with Unity (tv-related) I am more then happy to talk about it. in fact there are many things that I do not know what to do. Thanks again for considering it.
[18:08] <aepound> Where would I send emails about misspellings on the ubuntu websites?  I find one every now and then , and just want to let someone know.... Thanks
[18:10] <bobweaver> aepound,  you have tried   #ubuntu-website ?
[18:10] <aepound> Nope, I hadn't found that yet.  Thanks,
[18:12]  * bobweaver is dyslexic , you should see some of my comments in my code . =) j/k I try to make them spelled right . 
[19:08] <fginther> cyphermox, did you see didrocks comment on https://code.launchpad.net/~mathieu-tl/libgrip/inline/+merge/135806?
[19:49] <cyphermox> fginther: guess that one got lost in the noise, I think it was working but I'll build and install the package locally now to be sure
[19:50] <fginther> cyphermox, no worries, let me know if it checks out and I'll make sure it gets merged.