[07:46] <didrocks> mmrazik: hey! do you know what is happening on https://code.launchpad.net/~robru/qtubuntu-cameraplugin-fake/packaging/+merge/153652/comments/339216 ?
[07:48] <mmrazik> didrocks: the package needs rocket-scientists PPA for some reason (need to find out for what dep) but the rocket scientists ppa has no raring packages
[07:48] <mmrazik> if it is just mir I can change it to mir-team...
[07:49] <mmrazik> didrocks: there are lots of raring related failures. sergiusens is going through them.
[07:49] <didrocks> mmrazik: can you please comment on the MP?
[07:50] <mmrazik> didrocks: sure
[07:50] <didrocks> thanks :)
[07:50] <mmrazik> didrocks: is it something that needs to be merged asap?
[07:50] <didrocks> mmrazik: no, that's fine
[07:50] <didrocks> mmrazik: I prefer that we start bootstrapping one after another all the packages in the stack
[07:50] <didrocks> from top to bottom
[07:51] <mmrazik> didrocks: sergio just decided to move everybody to raring right away to force the porting. IMHO also a valid approach (even though I would most likely do it differently too)
[07:52] <didrocks> mmrazik: right, I'm talking about creating the stack and have daily release/cleaned packaging
[07:53] <didrocks> mmrazik: oh also, we will probably start to move some stacks from head to raring/
[07:53] <didrocks> mmrazik: as long as upstream didn't fix their head though, we will just comment the branches
[07:54] <mmrazik> didrocks: all these failures are in the phablet directory
[07:54] <mmrazik> nothing in head
[07:54] <didrocks> mmrazik: yeah, that's not related, just warning you about that :)
[07:54] <mmrazik> k
[08:08] <didrocks> mmrazik: see rev 108
[08:17] <mmrazik> didrocks: ack
[08:30] <Saviq> tsdgeos, hey, I don't think phablet-mods-merged is feasible... 100k diff...
[08:31] <Saviq> tsdgeos, I'd rather "save" the current phablet-mods branch as legacy
[08:32] <Saviq> tsdgeos, and build on lp:unity by a) cherry-picking from phablet-mods (I believe there's only a handful of commits we're interested in)
[08:32] <tsdgeos> Saviq: you're going to have a huge diff anyways if we want to merge to lp:unity/phablet-mods
[08:32] <tsdgeos> what i can do is reduce the diff against lp:unity
[08:32] <Saviq> tsdgeos, no, we're going to move that away
[08:32] <Saviq> tsdgeos, and push lp:unity as new lp:unity/phablet-mods
[08:32] <Saviq> tsdgeos, and cherry-pick into it
[08:33] <tsdgeos> ok
[08:33] <Saviq> tsdgeos, it's gonna get maintainable at least
[08:34] <tsdgeos> Saviq: but to make it build in quantal i still need to comment lots of stuff in the CMakeLists, are we still ok with that?
[08:34] <Saviq> tsdgeos, yeah
[08:34] <Saviq> tsdgeos, but at least we'll see the diff
[08:35] <tsdgeos> Saviq: you can see the diff if you do bzr diff --old lp:unity
[08:35] <Saviq> tsdgeos, hmm I tried that,
[08:35] <Saviq> tsdgeos, it was huge, too?
[08:35] <tsdgeos> you get a huge thing because for some reason all the .po files are different
[08:35] <tsdgeos> and someone added lots of ADD_DEBUG_HERE
[08:35] <tsdgeos> but otherwise is "smallish"
[08:36] <Saviq> ah!
[08:36] <tsdgeos> Saviq_: what's the last thing you saw?
[08:36] <Saviq> my VPS is back
[08:36] <Saviq> tsdgeos, meaning?
[08:36] <tsdgeos> ah ok, no disconnection
[08:37] <Saviq> :)
[08:37] <Saviq> tsdgeos, still 40k diff ;)
[08:37] <tsdgeos> ok
[08:37] <Saviq> tsdgeos, thing is, lp:unity/phablet-mods
[08:37] <Saviq> tsdgeos, includes the changes that were made for Nux phone shell
[08:37] <tsdgeos> so i'll create a new branch and cherry-pick from it
[08:37] <tsdgeos> yes
[08:38] <tsdgeos> like making icons bigger and stuff
[08:38] <Saviq> tsdgeos, so let's cut that fruit
[08:38] <Saviq> it's gonna make our lives easier
[08:38] <tsdgeos> ok
[08:39]  * tsdgeos starts again :-)
[08:40] <Saviq> tsdgeos, sorry, I thought that was the plan from the get go, bad comm on /me
[08:41] <tsdgeos> no worries, my fault for not rechecking at middle journey yesterday
[09:21] <didrocks> dednick: sil2100: hey, FYI, last results are available for autopilot release testing
[09:21] <didrocks> dednick: sil2100: ignore nvidia, it's a UTAH issue
[09:24] <dednick> looks like there's still some wait time issues with dash results. may need to increase. would have thought 10 seconds for a category would be enough :S
[09:26] <mzanetti_> Saviq: hey
[09:26] <mzanetti_> Saviq: I was updating our build-deps and noticed there is still python2.7 in there
[09:30] <Saviq> mzanetti, you have a MR for that don't you?
[09:30] <mzanetti> Saviq: iirc you had one..
[09:30] <Saviq> mzanetti, remember we haven't merged anything since last week due to failing raring builds
[09:31] <mzanetti> ohhh... now I remember.. you fixed it in indicators
[09:31] <mzanetti> ok. makes sense again
[09:37] <sil2100> dednick: I bumped it to 25 seconds for shopping results, since that's the average time it takes sometimes to fetch a shopping result ;/
[09:38] <dednick> sil2100: how do you increase the result wasit timeout? is there a variant of Eventually?
[09:39] <dednick> sil2100: was just about to look into that
[09:39] <sil2100> dednick: you just add the timeout parameter to the Eventually call
[09:39] <dednick> sil2100: ahh
[09:40] <sil2100> So it's like Eventually(value, timeout=25)
[09:40] <sil2100> dednick: it's neat ;)
[09:40] <sil2100> Anyway I filled this in yesterday anyway https://bugs.launchpad.net/unity/+bug/1159989
[09:40] <Saviq> mzanetti, I wonder, though, if we should investigate why python2.7 is not enough...
[09:41] <sil2100> Maybe it's the same thing for all 100scopes results really
[09:41] <mzanetti> Saviq: probably... but I tried for a while and couldn't reproduce it anywhere... its only failing in the ppas
[09:41] <mzanetti> which makes it really hard to debug
[09:42] <Saviq> mzanetti, I can reproduce it locally in a clean sbuild
[09:42] <Saviq> clean as in _really_ clean - a bootstrap, really
[09:42] <davidcalle> sil2100, have you tried this morning build of libunity? It's a lot faster for all scopes.
[09:42] <mzanetti> Saviq: this is the line that needs to pass: python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()
[09:43] <mzanetti> Saviq: so the question is, why does distutils.sysconfig not get pulled in there by python2.7 but by python
[09:43] <Saviq> mzanetti, it actually does get pulled in, AFAIK, but it doesn't work
[09:44] <Saviq> mzanetti, ah
[09:44] <Saviq> mzanetti, there's no python in $PATH
[09:44] <Saviq> mzanetti, so the correct fix is to go with `python2.7 -c "from distutils.sysconfig import get_python_lib; print get_python_lib()"`
[09:45] <Saviq> mzanetti, instead of s/python2.7/python/ in build deps
[09:46] <mzanetti> Saviq: ah ok... makes sense. sergio said we shouldn't use a harcoded python version anyways.
[09:47] <mzanetti> Saviq: My experience with python is not good enough to give a qualified opinion. It works both now, but I don't know which one is more future proof.
[09:49] <Saviq> mzanetti, not using a hardcoded version might mean that suddenly python3 will become default and it will stop working most probably
[09:50] <mzanetti> Saviq: yep... just tested it with python 3.3... fails for invalid syntax
[09:51] <mzanetti> Saviq: ok. lets make it 2.7 then. cheers
[09:51] <Saviq> mzanetti, "print(thing)" instead of "print thing"
[09:51] <Saviq> mzanetti, but that's not even that
[09:51] <Saviq> mzanetti, if you run it with python3
[09:51] <Saviq> mzanetti, it will return /usr/lib/python3/dist-packages
[09:52] <mzanetti> Saviq: that would be ok
[09:52] <Saviq> so the autopilot tests would get installed _for_ python3
[09:52] <Saviq> mzanetti, assuming the tests work with python3 ;)
[09:52] <mzanetti> Saviq: right...
[09:52] <mzanetti> yeah. full ack. 2.7 it is
[10:03] <sil2100> davidcalle: hm, didn't upgrade yet, will try thanks! :)
[10:03] <sil2100> If it helps, then it would be awesome
[10:03] <sil2100> davidcalle: is it in the experimental PPA?
[10:03] <davidcalle> sil2100, yes
[10:03]  * sil2100 upgrades
[10:12] <Saviq> mzanetti, TBH CMake is nasty, then - instead of failing on the command it just went over and said the text was empty...
[10:12] <mzanetti> Saviq: yeah... doesn't make it any easier to debug
[10:17] <Saviq> mzanetti, http://www.cmake.org/cmake/help/cmake2.6docs.html#command:execute_process - we should check RESULT_VARIABLE and ERROR_VARIABLE
[10:27] <sil2100> davidcalle: ok, so I tried the latest libunity and even though normal results appear indeed faster now, I have the same problem with shopping results sadly ;/
[10:32] <davidcalle> sil2100, so, everything is fine :p IIRC libunity team were investigating it this morning.
[10:32] <sil2100> I even wonder what's wrong with the unity.tests.test_shopping_lens.ShoppingScopeTests.test_application_scope_has_shopping_results test failing
[10:33] <sil2100> Since on jenkins searching for 'Text Editor' in the app scope seems to return no results at all!
[10:33] <sil2100> Big huh
[10:34] <mzanetti> Saviq: https://code.launchpad.net/~mzanetti/unity/phablet-better-cmake/+merge/155451
[10:37] <didrocks> + [mrazik] Prepare a list of stacks: DONE
[10:38] <didrocks> mmrazik: this is something I took action on btw in coordination with upstream ^
[10:38] <didrocks> mmrazik: I think it will changed from current configuration
[10:38] <didrocks> (and will be in the head release btw)
[10:43] <mmrazik> didrocks: ack and agreed. The "done" here more or less means the projects have been identified and "somehow" stacked. There is still some work to do (I think sergio even added some TODOs into the cfgs)
[10:44] <didrocks> mmrazik: ok, sounds good :-)
[11:29] <kaleo_> Saviq: hey can I ask you a favor?
[11:29] <Saviq> kaleo_, you can try
[11:30] <kaleo_> Saviq: can you check unity is fine with Qt 5.0.1?
[11:31] <Saviq> kaleo_, which PPA?
[11:31] <kaleo_> Saviq: https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta-proper/+packages
[11:38] <Saviq> kaleo_, yeah, Qt 5.0.1 seems fine
[11:43] <kaleo_> gret
[11:44] <Saviq> we do have a crash on every search now :/ but that seems unrelated to the version of qt
[12:07] <tsdgeos> Saviq_: Saviq: lp:~aacid/unity/phablet-mods-cherrypicked
[12:08] <Saviq> tsdgeos, thanks
[12:08] <mmrazik> didrocks: the "to_transition" thing breaks ci/autolanding :-/
[12:08] <mmrazik> didrocks: what is the intended use of that?
[12:08] <tsdgeos> Saviq: builds fine in quantal (device and VM), i'm checking raring VM now, any idea what to do with raring device? shall i try to update the device?
[12:08] <didrocks> mmrazik: how break? the idea is to ignore those projects
[12:08] <didrocks> mmrazik: they are in raring/* for now
[12:09] <didrocks> so you still have the references to the branches
[12:09] <mmrazik> didrocks: right -- the CI job generator ignores those projects
[12:09] <Saviq> tsdgeos, nah, that won't work probably
[12:09] <didrocks> mmrazik: that's the goal :)
[12:09] <didrocks> mmrazik: you have them in raring
[12:09] <mmrazik> didrocks: the goal is to have no autolanding for lp:mir?
[12:09] <mmrazik> oh
[12:09] <didrocks> mmrazik: ah, mir is an oversight, should be only in main
[12:09] <didrocks> mmrazik: let me fix that :)
[12:09] <tsdgeos> Saviq: that's what i thought too
[12:09] <mmrazik> didrocks: thanks (and got it)
[12:09] <didrocks> mmrazik: FYI https://wiki.ubuntu.com/DailyRelease/MovingNewRelease
[12:10] <didrocks> mmrazik: I didn't reread it yet
[12:10] <tsdgeos> Saviq: so? just dump it into the ppa builders?
[12:10] <didrocks> mmrazik: feedback welcome :)
[12:10] <didrocks> mmrazik: rev 116, back mir on head
[12:10] <Saviq> tsdgeos, I'll move the branches around, you'll MR your branch to lp:unity/phablet-mods
[12:10] <didrocks> (and removed from raring)
[12:10] <Saviq> tsdgeos, and we'll see what jenkins has to say
[12:10] <tsdgeos> ok
[12:11] <tsdgeos> i tried MR-ing it against lp:unity/phablet-mods right now i get billions of conflicts
[12:11] <tsdgeos> since it's not based in that branch
[12:11] <tsdgeos> so makes sense :D
[12:12] <mmrazik> didrocks: thx
[12:12] <Saviq> tsdgeos, done https://code.launchpad.net/~unity-team/unity/phablet-mods
[12:13] <didrocks> mmrazik: it's the easiest workflow I can think of, but I'm really interested in your feedback :)
[12:13] <Saviq> tsdgeos, that's lp:unity/phablet-mods now
[12:14] <tsdgeos> okidoki
[12:15] <mmrazik> didrocks: I find it a bit counter-intuitive to have stuff in stacks/raring while the projects target_branch is trunk
[12:15] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity/phablet-mods-cherrypicked/+merge/155469 a diff that fits in the webpage! :
[12:15] <tsdgeos> :D
[12:16] <Saviq> tsdgeos, yup :)
[12:16] <mmrazik> didrocks: why aren't we branching to lp:$project/raring while doing the cp?
[12:16] <didrocks> mmrazik: this is step 2
[12:16] <didrocks> mmrazik: step1 is better done in one shot
[12:16] <didrocks> then, everyone responsible for his stack can go over step2
[12:17] <mmrazik> ok. need to go through the whole thing
[12:18] <Saviq> tsdgeos, why don't we comment out the whole of hud, panel, dash etc?
[12:18] <Saviq> tsdgeos, only leaving UnityCore and the tests that make sense?
[12:18] <mmrazik> didrocks: did you push the mir changes?
[12:18] <mmrazik> I don't see it
[12:18] <tsdgeos> Saviq: tried to keep the diff as minimal as possible regarding files not built
[12:19] <Saviq> tsdgeos, mhm
[12:19] <tsdgeos> basically to run the tests
[12:19] <tsdgeos> even if probably they don't "apply"
[12:19] <didrocks> mmrazik: oh sorry, diverged branch
[12:20] <Saviq> tsdgeos, did you try to search anything in the dash lately?
[12:20] <tsdgeos> nope
[12:21] <didrocks> mmrazik: 117
[12:21] <mmrazik> didrocks: thx
[12:21] <didrocks> yw :)
[12:23] <Saviq> tsdgeos, crash in QQuickVisualDataModel::_q_itemsRemoved
[12:24] <Saviq> tsdgeos, every time
[12:24] <tsdgeos> ouch
[12:25] <tsdgeos> Saviq: when did that start?
[12:25] <Saviq> tsdgeos, not sure
[12:25] <tsdgeos> we didn't do anything there, did we?
[12:25] <tsdgeos> hmmm, wait i think mzanetti did some refactor in the history of searchs
[12:25] <mzanetti> yes
[12:26] <mzanetti> however, the crash has been there already before
[12:26] <mzanetti> at least for me
[12:26] <tsdgeos> i could make it crash "sometimes"
[12:26] <tsdgeos> not always
[12:26] <tsdgeos> i guess always is better? :D
[12:26] <mzanetti> I can't use the search at all. crashes 100%
[12:26] <Saviq> in a sense, yes
[12:26] <Saviq> mzanetti, yup, same here
[12:26] <mzanetti> and for me just starting the shell crashes too
[12:26] <mzanetti> in 80% of the cases
[12:27] <mzanetti> if I pass -geomtry 1600x1200 it gets more stable
[12:27] <mzanetti> it seems the faster the hardware, the more it crashes
[12:27] <tsdgeos> weird
[12:27] <tsdgeos> never happened here
[12:27] <mzanetti> doesn't crash in slow jenkins at all
[12:28] <tsdgeos> Saviq: ok, build on raring VM too, so unless you want me to do a "bigger cut" of things we built, it should be ok from my side
[12:28] <tsdgeos> let's see what CI says :D
[12:28] <Saviq> tsdgeos, looking at launcher/CMakeLists.txt for example...
[12:29] <Saviq> tsdgeos, there's barely anything left
[12:29] <tsdgeos> half of the files
[12:29] <tsdgeos> yeah
[12:30] <tsdgeos> no binary but the files still get linked to the tests
[12:37] <Saviq> tsdgeos, mzanetti it's the carousel - r478
[12:37] <mzanetti> interesting...
[12:43] <tsdgeos> weird
[12:43] <tsdgeos> lunch
[13:14] <luv> mardy: hey! did you get my messages yesterday? ... only relevant library i have installet in the system is libsignon-plugins-common.so but it exports different symbols than oauth plugin is asking for
[13:15] <luv> http://pastebin.blesmrt.net/3103/
[13:16] <mardy> luv: yes, I proposed a fix: https://code.launchpad.net/~mardy/signon/packaging/+merge/155425
[13:16] <luv> you guys are fast :-) great job, thanks!
[13:17] <luv> im afraid installing .a wont be enough, because it uses -lsignon-plugins to link - maybe oauth needs to be changed to link statically against signog-plugins?
[13:17] <luv> signon
[13:19] <luv> anyway, i can try when i get back home and eventually fix oauth plugin accordingly
[13:20] <Saviq> tsdgeos, you saw it failed?
[13:47] <tsdgeos> Saviq: yes but afaik was CI itself failing no?
[13:47]  * tsdgeos looks again
[13:47] <Saviq> tsdgeos, possibly, I restarted
[13:48] <tsdgeos> Saviq: ok, one was ccache failing for some weird reason
[13:48] <tsdgeos> there's two more that have
[13:48] <tsdgeos> test-gtest-xless: /build/buildd/ubuntu-platform-api-0.18/src/android/ubuntu_application_api.cpp:51: {anonymous}::Bridge::Bridge(): Assertion `lib_handle && "Error loading ubuntu_application_api"' failed.
[13:48] <tsdgeos> that i have no idea why may be happening
[13:49] <dandrader> greyback, would you have some time to review this? https://code.launchpad.net/~dandrader/unity/phablet_tst_Stage/+merge/155489
[13:49] <dandrader> Tests for Stage.qml
[13:50] <tsdgeos> mzanetti: mmrazik: any idea why test-gtest-xless: /build/buildd/ubuntu-platform-api-0.18/src/android/ubuntu_application_api.cpp:51: {anonymous}::Bridge::Bridge(): Assertion `lib_handle && "Error loading ubuntu_application_api"' failed.  may be happening in the arm machines on running unity tests?
[13:50] <greyback> dandrader: tbh you've caught me at a terrible time. Can someone else take it?
[13:50] <dandrader> greyback, sure
[13:51] <greyback> sorry
[13:51] <mzanetti> tsdgeos: cant really follow...
[13:51] <mmrazik> tsdgeos: absolutely no clue :-/
[13:51] <mzanetti> dandrader: I'll take it
[13:51] <dandrader> mzanetti, thanks!
[13:53] <dednick> didrocks, sil2100: more ap test fixes. https://code.launchpad.net/~nick-dedekind/unity/smart-scopes.autopilot-build-18/+merge/155491
[13:53] <dednick> sil2100: can you review please?
[13:55] <Saviq> tsdgeos, try ricmm
[13:55] <mmrazik> mzanetti: ps-quantal-server-amd64-1 is back in the pool
[13:55] <mmrazik> mzanetti: and it looks like qmluitests were just scheduled there
[13:55] <mzanetti> mmrazik: thanks a bunch
[13:56] <mmrazik> mzanetti: mhm... is the failure my bug?
[13:56] <mmrazik> mzanetti: http://s-jenkins:8080/job/unity-phablet-qmluitests/13/console
[13:56] <mzanetti> mmrazik: no. its mine
[13:56] <mmrazik> ok
[13:56] <mzanetti> mmrazik: I'm still experimenting
[13:57] <mzanetti> mmrazik: right now the qmluitests just stall forever when jenkins executes them, but if I log in and execute the exact same pbuilder call everything is fine
[13:57] <mzanetti> sometimes I really wonder...
[13:58] <sil2100> dednick: aye!
[14:07] <tsdgeos> Saviq: i think it may have to do with the fact that the CI machine is *not* a device thus the ubuntu_application_api thing fails
[14:10] <mmrazik> didrocks: regarding https://wiki.ubuntu.com/DailyRelease/MovingNewRelease -- I would find it more logical to have the "to_transition" stenza in the new stack rather then head (as thats something that needs to be created while the head is there all the time). OTOH I get that it is more logical from your/distro POV do it this way
[14:10] <mmrazik> and in the end the result is the same
[14:11] <mmrazik> didrocks: I guess I just need to add stuff to the "redeploy all stacks" as you need to create the autolanding jobs for the new branches too
[14:11] <mmrazik> other than that looks good to me
[14:11] <mardy> luv: it should work, the linker -l resolves static libraries as well
[14:16] <sil2100> dednick: commented and approved, good catch!
[14:17] <didrocks> mmrazik: if you do that, you will need to deploy the stack 2 more times
[14:17] <dednick> sil2100: thanks
[14:17] <didrocks> mmrazik: and you can end up in more cases with "same data in both stack"
[14:18] <didrocks> mmrazik: rather than once raring and then transitionning
[14:18] <didrocks> mmrazik: I started the way you mentionned
[14:18] <didrocks> mmrazik: then, got 20 steps and started to revise to have something less error-prone :)
[14:18] <didrocks> hence the current proposed way
[14:18] <mmrazik> ok
[14:18] <mzanetti> Saviq: hey, I think it would make sense to include om26er in our standup. Can you update it please? I can only invite guests which doesn't put it in his calendar etc
[14:19] <Saviq> mzanetti, hum? you should be able to add just fine?
[14:19] <Saviq> mzanetti, they're all guests :D
[14:19] <mzanetti> oh... ok
[14:19] <mzanetti> it does look a bit differnt tho
[14:19] <Saviq> mzanetti, but done anyway
[14:19] <mzanetti> cheers
[14:20] <dednick> sil2100: i just pushed another 1 liner and bumped the approve. hope you dont mind ;)
[14:21] <sil2100> dednick: that's cool ;)
[14:21] <dednick> sil2100: just wanted to make sure that at least one cycle of wait_for_result_settle would get executed if dash was empty to start off
[14:23] <didrocks> dednick: thanks! will be in the next next rebuild (so tomorrow morning)
[14:23] <didrocks> dednick: but if we get the current build quick enough, I can maybe relaunch one (just unity)
[14:23] <om26er> mzanetti, now they appear in my calendar
[14:24] <dednick> didrocks: did the changes mhr3 was talking about get in?
[14:24] <mzanetti> om26er: ok, great
[14:24] <Saviq> mzanetti, remember that you have to save after adding a guest
[14:24] <Saviq> maybe that was why it didn't show up?
[14:24] <mzanetti> Saviq: haha... I guess thats it indeed
[14:24] <sil2100> dednick, didrocks: regarding the shopping scopes and the scopes long-time-to-display-results, pstolowski told me it's being worked on right now
[14:24] <mzanetti> yay for webapps!
[14:24] <didrocks> dednick: you mean https://code.launchpad.net/~mhr3/libunity/handle-scope-flags/+merge/155465?
[14:25] <mzanetti> I just love how consistent usability is among them
[14:25] <didrocks> dednick: it's in if you speak about them :)
[14:25] <didrocks> sil2100: nice :)
[14:25] <dednick> didrocks: yep, i think that's the ones.
[14:25] <dednick> ta
[14:27] <mzanetti> dandrader: really cool stuff :)
[14:27] <mterry> fginther, what's the story with the ci job trying to build in raring for merges against unity/phablet ?  They seem doomed to fail?
[14:27] <mzanetti> dandrader: why do you change the ApplicationScreenshots to properties?
[14:28] <dandrader> mzanetti, so that I can replace them with mock implementations in the test
[14:28] <fginther> mmrazik, can you answer mterry ^ ?
[14:29] <didrocks> mterry: hey! hot from the press: https://wiki.ubuntu.com/DailyRelease/MovingNewRelease
[14:29] <didrocks> mterry: I'm interesting in feedback
[14:29] <didrocks> kenvandine: as well ^
[14:29] <kenvandine> didrocks, i'll read :)
[14:29] <didrocks> thanks :)
[14:30] <mmrazik> mterry, fginther: its more of an question for sergiusens but they are not doomed to fail. You can just fix them :)
[14:30] <mmrazik> mterry: Ibelieve that is the motivation behind it  -- to force people to migrate to raring
[14:31] <mterry> mmrazik, but it has the effect of blocking all merges, right?
[14:31] <mmrazik> mterry: yup
[14:32] <mmrazik> mterry: if you have any specific concerns/something urgent to merge then talk to sergiusens. He is the guy behind this.
[14:34] <mterry> mmrazik, I just didn't think we had the pieces in place yet to handle raring, and the fault wasn't that unity devs were dragging their feet, but that distro people like me and didrocks were too busy with releassing raring to get to phablet on raring
[14:34] <mterry> mmrazik, so we're blocking people that have no power to unblock themselves...
[14:34] <mmrazik> mterry: can't comment on that
[14:35] <mmrazik> mterry: but nobody complained so far :)
[14:35] <mmrazik> or at least not to me
[14:35] <mterry> mmrazik, I just did.  ;)  I'll poke sergiusens
[14:35] <nic-doffay> Saviq, gonna have to skip standup today busy discussing Infographics. Still need someone to review the test case though.
[14:35] <Saviq> nic-doffay, k
[14:36] <mmrazik> mterry: there is actually a thread on this on the phablet mailing list
[14:36] <didrocks> mterry: btw, the page I pointed it the first step to have "head" and thus phablet ppa :)
[14:36] <mmrazik> mterry: where nobody really complied
[14:36] <mmrazik> err
[14:36] <mmrazik> complained
[14:40] <Saviq> om26er, can you hear us?
[14:41] <om26er> i could hear you all
[14:41] <om26er> Saviq, seems my mic is not working
[14:41] <om26er> for mumble only (?)
[14:41] <dednick> you got push to talk enabled?
[14:41] <Saviq> om26er, or your push-to-talk button?
[14:42] <mterry> didrocks, why does the plan involve disabling head, then re-enabling it one by one?  Don't our stack dependencies ensure that things will be built correctly in a fresh PPA?
[14:42] <mterry> Not to mention build-waiting
[14:43] <didrocks> mterry: we disable head because we are basically taking a snapshot of head and put that into raring
[14:43] <om26er> Saviq, i don;t think so. push to talk is not enabled
[14:44] <didrocks> mterry: if we don't do that, we'll have to tweak the deps on every stack we push to dep on "head", "qa"?
[14:44] <mterry> didrocks, sure, that's what the "raring" release is for (vs "head")
[14:45] <mterry> didrocks, I'm not sure I follow that last statement
[14:45] <didrocks> mterry: ok, let's discuss it in a hangout
[14:45] <mzanetti> om26er: hehe, that didn't really work out :)
[14:45] <mzanetti> om26er: when you think your mumble is working, let me know so we can test
[14:45] <om26er> mzanetti, it should, tomorrow
[14:46] <didrocks> mterry: in an hour?
[14:46] <om26er> mzanetti, i am installing it on a different machine right now
[14:46] <mterry> didrocks, sure
[14:46] <om26er> mzanetti, and i;ll poke you to test call
[14:46] <mzanetti> om26er: ok
[14:46] <mzanetti> om26er: and no worries. I don't know anyone yet that hasn't ever had an issue with mumble in the standup
[14:48] <MacSlow> Saviq, there you go https://code.launchpad.net/~macslow/unity/phablet-notification-renderer/+merge/155512
[14:50] <dandrader> tsdgeos, I got this error, which is unrelated to my merge proposal changes: http://pastebin.ubuntu.com/5649560/
[14:51] <dandrader> tsdgeos, from https://code.launchpad.net/~dandrader/unity/phablet_tst_Stage/+merge/155489/comments/339607
[14:51] <Saviq> MacSlow, cheers
[14:51] <dandrader> tsdgeos, have you seem anything similar
[14:51] <dandrader> ?
[14:51] <tsdgeos> dandrader: yes
[14:51] <Saviq> MacSlow, I'll try and post feedback today/tomorrow
[14:51] <tsdgeos> dandrader: that's the thing i've been working the last to days
[14:51] <tsdgeos> dandrader: we are stuck on raring merges at the momet
[14:51] <tsdgeos> +n
[14:52] <MacSlow> Saviq, great thanks... but it's not done yet :)
[14:52] <dandrader> tsdgeos, ah,ok. will that block merges for the time being?
[14:52] <Saviq> MacSlow, that's fine, just want to make sure you're not following some paths that will bite you later
[14:52] <MacSlow> Saviq, yup
[14:52] <tsdgeos> dandrader: unfortunately
[14:53] <dandrader> :(
[14:54] <tsdgeos> yep
[14:54] <tsdgeos> our merges are piling up
[14:54] <tsdgeos> i "think" i'm almost done
[14:54] <tsdgeos> CI is almost finished and then i'll nudge Saviq
[14:55] <tsdgeos> Saviq: kgunn: do we have a blueprint item for "port phablet-mods to a newer unity"? Given we've spent a considerable amount of time in it i think it should probably logged
[14:56] <Saviq> tsdgeos, it's more of a "migrate to raring" item, and no, we don'
[14:56] <Saviq> 't
[14:57] <Saviq> tsdgeos, I'll add
[14:57] <dandrader> mzanetti, the instability fix: https://code.launchpad.net/~dandrader/unity/phablet_tst_DashPreview_instability/+merge/155515
[14:58] <tsdgeos> Saviq: see https://code.launchpad.net/~aacid/unity/phablet-mods-cherrypicked/+merge/155469 along with my last comment, we can say CI has passed
[14:59] <mzanetti> dandrader: thanks a lot
[14:59] <dandrader> mzanetti, yw
[15:00] <Saviq> tsdgeos, yup, looks good, will wait for the CI to finish and look through the diff quickly
[15:01] <tsdgeos> oka
[15:01] <Saviq> tsdgeos, we'll need a release bump to v 7.80, too
[15:01]  * tsdgeos does
[15:02] <kgunn> any takers on https://code.launchpad.net/~nicolas-doffay/unity/page-header-test/+merge/155242
[15:04] <tsdgeos> Saviq: done http://bazaar.launchpad.net/~aacid/unity/phablet-mods-cherrypicked/revision/3259
[15:05] <Saviq> tsdgeos, cheers
[15:06] <Saviq> kgunn, not that easy, you need to point at people ;)
[15:07] <tsdgeos> kgunn: added a comment about why the raring part is broken if that's what you meant
[15:08] <kgunn> tsdgeos: thanks...no, was just wanting to get nick some review/feedback is any
[15:08] <kgunn> oops/is/if
[15:09] <kgunn> dandrader: would you mind reviewing https://code.launchpad.net/~nicolas-doffay/unity/page-header-test/+merge/155242
[15:10] <dandrader> kgunn, not at all. but didn't Saviq just do it
[15:10] <dandrader> ?
[15:10] <Saviq> kgunn, dandrader I mostly did...
[15:11] <Saviq> dandrader, please only mark things DONE in the bp when they're merged
[15:11] <dandrader> Saviq, ah, ok. sorry
[15:11] <kgunn> Saviq: dandrader stale webpage....sorry :)
[15:11] <kgunn> dandrader: plus Saviq said point at people...so i did
[15:11] <kgunn> :)
[15:13] <tsdgeos> kgunn: Saviq: mzanetti: i see i have the "HUD testing" blueprint item in both https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-hud-2-ui and https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-testing does it really make sense to have it twice?
[15:13] <Saviq> tsdgeos, no, just leave one of them in
[15:14] <tsdgeos> ok
[15:14] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity/phablet-mods-cherrypicked/+merge/155469 CI appoved
[15:16] <didrocks> mterry: kenvandine: cyphermox: I have half an hour now, ok for a hangout with this deployment doc?
[15:17] <cyphermox> yeah
[15:17] <didrocks> mterry: kenvandine cyphermox: https://plus.google.com/hangouts/_/4340e3dc7f93270210e58a9d8fd05d667f23b13a?authuser=0&hl=en
[15:19] <Saviq> tsdgeos, huh? libunity-2d-private? wth?
[15:19] <Saviq> where did it build that from :D
[15:20] <tsdgeos> Saviq: from thin air :D
[15:20] <tsdgeos> Saviq: i guess someone decided unity should build empty unity-2d packages now that we don't package unity-2d anymore
[15:20] <tsdgeos> or something
[15:20] <Saviq> tsdgeos, ar right
[15:32] <Saviq> tsdgeos, it's alive! ;)
[15:36] <tsdgeos> Saviq: :)
[15:36] <Saviq> tsdgeos, another ccache failure is incoming, though
[15:36] <tsdgeos> oh my
[15:37] <Saviq> hopefully autolanding will be fine
[15:48] <mterry> didrocks, does Enter activate the first search result for you with 100 scopes?
[15:48] <mterry> didrocks, doesn't seem to for me, which is a regression
[15:49] <mterry> Hrm... It does, but only after all results are in, maybe?
[15:49] <tsdgeos> Saviq: any idea when/if autolanding triggers?
[15:50] <Saviq> tsdgeos, good question
[15:50] <Saviq> mterry, yeah, I have a similar experience
[15:51] <mterry> Saviq, hrm.  do you have a guess who to ping about it?
[15:51] <mterry> tsdgeos, ^?
[15:52] <tsdgeos> mterry: no idea sorry
[15:52]  * mterry files bug
[15:52] <Saviq> mterry, yup, do that
[15:52] <Saviq> mterry, add 100scopes as tag
[15:53] <tsdgeos> mmrazik: mzanetti: do you know when/if autoloanding triggers for the phablet-mods MRs?
[15:53] <Saviq> tsdgeos, already pinged mmrazik
[15:53] <mmrazik> tsdgeos: */15 * * * *
[15:53] <tsdgeos> oki, sorry :-)
[15:53] <mmrazik> + some time to process your particular branch
[15:53] <mmrazik> tsdgeos: the branch was locked. released it so it should be picked in ~7mins
[15:54] <tsdgeos> mmrazik: ok, tx
[16:04] <mmrazik> didrocks: in case you have a sec: https://code.launchpad.net/~mrazik/cupstream2distro-config/webcred/+merge/155541
[16:04] <mmrazik> didrocks: just to confirm I'm using the to_release correctly
[16:14] <didrocks> mmrazik: why account-plugins is not in to_transition?
[16:14] <mmrazik> didrocks: it has both trunk and 13.04 branch
[16:14] <didrocks> mmrazik: we'll do that thursday if you don't mind
[16:14] <didrocks> mmrazik: I need to deploy the stacks
[16:14] <didrocks> mmrazik: and I want to do a check before and then after
[16:15] <didrocks> mmrazik: but yeah, the idea is good otherwise :)
[16:15] <didrocks> just I'm not a huge fan of:
[16:15] <didrocks> signon-keyring-extension:
[16:15] <didrocks>    target_branch: lp:signon-keyring-extension
[16:16] <didrocks> is the repetition needed?
[16:16] <didrocks> I handle that as "default"
[16:16] <didrocks> to avoid having too much lines in the config
[16:17] <mmrazik> didrocks: its because I expect people will just add /13.04
[16:17] <mmrazik> and delete in head
[16:17] <mmrazik> I can probably delete in head right away
[16:17] <mmrazik> I just did it for raring and then copied to head
[16:18] <mmrazik> didrocks: so should account-plugins stay in to_transition?
[16:18] <didrocks> mmrazik: well, and remove the 13.04 branch if possible
[16:18] <didrocks> for it
[16:18] <didrocks> just until thursday
[16:18] <didrocks> mmrazik|otp: I want to test the new procedure
[16:18] <didrocks> mmrazik|otp: but I'm not there tomorrow
[16:18] <didrocks> and a build thursday "normal"
[16:18] <didrocks> then deploying this
[16:19] <didrocks> and testing again :)
[16:19] <didrocks> mmrazik|otp: sounds good?
[16:23] <didrocks> kenvandine: FYI ^
[16:23] <kenvandine> didrocks, ok
[16:31] <rickspencer3> hey all
[16:31] <rickspencer3> my panel froze :/
[16:32] <rickspencer3> oh, it just unfroze :/
[16:32] <davidcalle> didrocks, do you mind looking at https://code.launchpad.net/~submarine/ubuntu-scopes/yelp-limit-results/+merge/155076 , the yelp scope is currently returning an unhealthy number of results.
[16:33] <didrocks> davidcalle: looking
[16:38] <mmrazik> didrocks: back to the accoung-plugins -- the thing is that if I move it back to "to_transision" I won't be able to generate ci/autolanding jobs for trunk
[16:39] <mmrazik> didrocks: I had hoped that with daily_release set to False it won't generate any job for the distro stuff
[16:39] <didrocks> mmrazik: it shouldn't
[16:39] <didrocks> mmrazik: but I would have hope to check the process once first :/
[16:39] <didrocks> mmrazik: do they really need those branches today?
[16:39] <didrocks> can't wait on thursday?
[16:40] <mmrazik> didrocks: I had an impression kenvandine wants to land something to the /13.04
[16:40] <mmrazik> didrocks: but I wonder why it needs to wait when it should have no effect on your stuff
[16:40] <didrocks> kenvandine: I told that we should wait on thursday, isn't it? ^
[16:40] <kenvandine> mmrazik, not really, mardy merged it i think
[16:41] <didrocks> mmrazik: I want to test a before run/after run
[16:41] <kenvandine> didrocks, not related to daily releases
[16:41] <didrocks> mmrazik: to ensure the workflow makes sense
[16:41] <didrocks> kenvandine: changing the stack config impact daily releases
[16:41] <kenvandine> mardy branched for 13.04 to add new features to trunk
[16:41]  * kenvandine wasn't changing the config :)
[16:41] <mmrazik> didrocks: how does what I proposed change the daily release?
[16:41] <didrocks> mmrazik: because this file is read by the daily releases
[16:42] <kenvandine> so mardy had me upload a bug fix proposed against their 13.04 branch
[16:42] <didrocks> kenvandine: urgh
[16:42] <mmrazik> didrocks: but all of it should be ignored due to "daily_release: False" or am I missing something?
[16:42] <didrocks> kenvandine: so you *need* to deploy the daily today right?
[16:42] <didrocks> kenvandine: to point to none trunk
[16:42] <kenvandine> didrocks, it isn't daily
[16:42] <didrocks> mmrazik: it should, but I'm not here today and I didn't test it
[16:42] <didrocks> tomorrow*
[16:42] <didrocks> kenvandine: ah, not that one
[16:42] <kenvandine> right :)
[16:43] <Saviq> tsdgeos, just so you know, don't worry if it doesn't merge today (although I know you'd rather push it to the end)
[16:43] <Saviq> tsdgeos, we'll take over
[16:43] <didrocks> mmrazik: it's just I was hoping we can just wait on me being back and not complicating things over for nothing :(
[16:43] <tsdgeos> Saviq: sure, just want to see it in :D
[16:43] <mmrazik> didrocks: the "daily_release: False" stuff is not new one. What needs to be tested?
[16:43] <didrocks> we already have too much on each ones plate to take risk
[16:44] <didrocks> mmrazik: well, it wasn't in any of the stack when having a target_branch
[16:44] <didrocks> so it wasn't taken into account
[16:46] <didrocks> mmrazik: if you are around tomorrow to fix the daily release if things go wrong, I don't care :-)
[16:46] <mmrazik> didrocks: TBH I still don't get it but as you wish
[16:46] <mmrazik> didrocks: what could possibly go wrong? We have jenkins jobs to daily release stuff we don't want to daily release?
[16:46] <didrocks> mmrazik: let's coordinate this on Thursday, it will be a nice "first example" to transition to this workaround
[16:46] <didrocks> s/workaround/workflow/
[16:47] <mmrazik> didrocks: I'm not here for most of the Thu (have an appointment at US embassy to get Visas)
[16:47] <didrocks> mmrazik: as we are deploying stuff, it's different folders used for daily release
[16:47] <mmrazik> didrocks: there is something broken here. We can't create autolanding jobs because of something daily-release related. These two things should be independent
[16:48] <didrocks> mmrazik: it should be fine and have no impact
[16:48] <didrocks> mmrazik: but as it's the first time, I want to confirm first
[16:48] <didrocks> and be here if things go wrong
[16:48] <mmrazik> ok
[16:49] <didrocks> mmrazik: we just deployed this common config, I think rather than arguing, we should try to mitigate and lower the impact :)
[16:49] <didrocks> it's just a "just in case thing"
[16:49] <didrocks> if this goes wrong, nobody will be able to fix it tomorrow
[16:50] <mmrazik> didrocks: ok
[17:01] <robru> didrocks, hangout?
[17:01] <didrocks> robru: yep, you should have the link in the invite :)
[17:04] <didrocks> kenvandine: cyphermox mterry : joining?
[17:04] <mterry> didrocks, coming, hold on
[17:05] <tsdgeos> Saviq: failed again :/
[17:06] <tsdgeos> Saviq: i have to go, will try to come back in a couple of hours or so
[17:30] <cyphermox> argh, I can't believe how hangouts crash all the time here
[18:01] <mterry> didrocks, so..  what's the PPA name again for the phablet auto-uploading bits? experimental-certified?
[18:02] <didrocks> mterry: it will be daily-build-next
[18:02] <didrocks> (the final one will be "next")
[18:03] <mterry> OK, nothing in there yet
[18:03] <rtdrury> Hi!  I just viewed the Unity page for the first time and the question stands out there: What is Unity?  The answer below does not answer the question What is Unity?  Instead it answers What Does Unity Do?
[18:04] <rtdrury> Could the Ubuntu team change the answer so that it answers the question What is Unity?
[18:04] <rtdrury> Is there anyone here who can take this request to the relevant people?
[18:06] <rtdrury> All silent?  Whay is this?  My expectation is of a nomal gathering of people interacting in ways to build a more common understanding of the wold, specifically of a linux distro?
[18:10] <sil2100> rtdrury: hi! I'm sure if anyone with the power to resolve this issue was around he/she would answer - you can't get angry because currently there is no such person online
[18:11] <rtdrury> So we want that up  is up and down is down, white is white, black is black.  So povide direct information.  Keep Madison Ave out of the communications in the frree software community.  Unity is probaby some merging of Gnome & KDE.  But the question wasn't answered.  People want to know what it is first.
[18:11] <sil2100> I will try to remember this and forward it to someone that could be able to resolve this issue
[18:12] <rtdrury> Oh thanks - you'e a lifesaver, sil2100.  Have a great day.  My anger is well under control.  Ubuntu is great.  I just want to keep it great.  Ya know?  How are you?
[18:13] <sil2100> Thank you, I'm rather fine, how about you?
[18:13] <sil2100> Just a bit busy maybe
[18:15] <rtdrury> Yeah, vey busy here too.  It's been a long time since enering a chat room.  I think these are great.
[18:17] <rtdrury> So I'm upgrading from Lucid Lynx I think it is.  I'd like to thank all the volunteers.  Do you code?  Do you know what volunteer help is needed most?
[18:19] <sil2100> rtdrury: oh, excellent - yes, I code most of the time, although I have some packaging tasks as well - help is welcome basically everywhere, as always!
[18:19] <sil2100> rtdrury: are you a programmer as well?
[18:20] <sil2100> If you're upgrading, Unity might seem a bit 'different' to you: there's a lot of things an usuall Gnome user needs to get used to
[18:20] <rtdrury> I did lots of C codle in the past, and these dats doing more C code, using Gnome, have a Java project, and lots of PHP, Javascript & Bash scripts.
[18:22] <rtdrury> Oh mainly need for Gnome to work - I mainly want to use Ardour music studio with my Gnome-based plugins.
[18:23] <rtdrury> Ah so Unity is a desktop environment?
[18:23] <mhall119> it's a shell for Gnome DE
[18:23] <mhall119> currently
[18:23] <mhall119> Unity Next will be a bit more than that
[18:25] <rtdrury> Great - I noticed Gnome's API is evolving rapidly with lots of depreciated classes.  GUI evolution.
[18:26] <rtdrury> Well, I think you guys are doing the world a huge service by just being available here to answer questions.
[18:26] <mhall119> Unity is currently Gnome - (Gnome Shell) + (Unity Shell)
[18:26] <mhall119> if that math makes sense :)
[18:27] <rtdrury> Sure, I can see that is a superposition - a fancy word for summation
[18:28] <rtdrury> So you have the two shells to choose from?
[18:29] <mhall119> two shells for Gnome DE, but also KDE, Xfce, LXDE, and many others
[18:31] <rtdrury> I'd glad that you can see the bigger picture, seeing different people using different graphical environments.
[18:31] <sil2100> rtdrury: with Unity set as the default environment
[18:31] <sil2100> But allowing switching at will, depending on preferences
[18:32] <rtdrury> Well that's great - look guys, I have a huge load of work to do - this chat session has been great - this is the future.  Access to real live humans when it's really needed.  Keep up the great work.
[18:32] <mterry> didrocks, is there going to be a separate MIR bug for the 100 scopes?
[18:33] <didrocks> mterry: depends on your preferences
[18:33] <sil2100> cyphermox: ping, are you still around?
[18:33] <mterry> didrocks, no rush, just ping me when you make it, I have comments ready
[18:33] <didrocks> mterry: as everything is listed in the FFe, that's fine by me
[18:33] <didrocks> mterry: if you prefer a separate MIR bug, I can do it
[18:33] <mterry> didrocks, I'd prefer separate, just so I don't pollute the status field of the FFe
[18:34] <mterry> Huh, qtpim never made it to raring
[18:34] <mterry> Nor did libtelepathy-qt5...
[18:34] <didrocks> mterry: ok, if I prepare it on thursday, that's fine?
[18:35] <mterry> didrocks, sure...  I think the only blocker was the privacy issue
[18:35] <didrocks> mterry: yeah, which is addressed now, isn't it pstolowski? ^
[18:35] <mterry> didrocks, the bug is still open.  bug 1158782
[18:35] <pstolowski> mterry, didrocks: right, it's supported now
[18:36] <didrocks> pstolowski: please close the bug! :)
[18:36] <pstolowski> it wasn't assigned to home scope nor libunity ;)
[18:37] <pstolowski> didrocks: updated (except for 'unity (Ubuntu)' - not sure)
[18:38] <didrocks> pstolowski: you can close it
[18:38] <didrocks> pstolowski: those bugs never ended up in the distro
[18:38] <didrocks> so fine to not list them
[18:39] <cyphermox> sil2100: yeah I'm around
[18:43] <mterry> didrocks, in which PPA should I put packages like qtpim and telepathy-qt5 that aren't upstreams we watch, but are not yet in raring?
[18:43] <didrocks> mterry: we will need them to build the touch stack in the end, right?
[18:43] <sil2100> cyphermox: aaactually, I think I found a solution already - but would you mind if I poke you with some packaging branches for a review?
[18:44] <mterry> didrocks, right, they are deps of at least phone-app
[18:44] <cyphermox> sil2100: sure
[18:44] <didrocks> mterry: so daily-build-next for now
[18:44] <mterry> didrocks, just manually copy them in there?  sure
[18:44] <didrocks> mterry: manual copy or upload :)
[18:44]  * mterry tries to find the source for telepathy-qt5
[18:44] <didrocks> mterry: do you mind noting those things in the whiteboard of the blueprint?
[18:44] <mterry> ok
[18:44] <didrocks> mterry: so that we don't loose track on them
[18:44] <didrocks> thanks :)
[19:00] <seb128> cyphermox, mterry: could you get https://code.launchpad.net/~seb128/indicator-datetime/systemd-packaging-update/+merge/155584 reviewed/acked
[19:00] <seb128> it's based on top of https://code.launchpad.net/~desrt/indicator-datetime/timedated/+merge/151560
[19:00] <cyphermox> ok
[19:00] <seb128> I will land the other places in raring in a bit
[19:00] <seb128> thanks
[19:00] <cyphermox> that's fixing a current bug in raring
[19:00] <seb128> but it would be good to have that in the vcs so we can autoland the indicator for the transition
[19:00] <mterry> cyphermox, thanks. I have to run out for an errand
[19:00] <cyphermox> should be targetted to indicator-datetime/13.04 instead
[19:01] <cyphermox> mterry: all good, it's my stack anyway :)
[19:01] <seb128> cyphermox, thanks
[19:01] <seb128> https://code.launchpad.net/~seb128/indicator-datetime/systemd-packaging-update/+merge/155585
[19:01] <seb128> target updated
[19:01] <cyphermox> seb128: how did you do this so fast?
[19:01] <cyphermox> I'm curious ;)
[19:02] <seb128> clicked "resubmit" in the launchpad web ui
[19:02] <seb128> changed the target, pressed the button
[19:02] <seb128> I did base my work on the right vcs
[19:02] <seb128> just launchpad ui got it wrong
[19:03] <cyphermox> oh, of course
[19:03] <cyphermox> duh
[19:04] <cyphermox> hmm
[19:04] <cyphermox> desrt's branch is failing to build, but not due to his changes
[19:32] <cyphermox> seb128: there's a conflict, can you fix it?
[19:47] <seb128> cyphermox, hey, was away for dinner, sure ... should I just merge the fixes into one mr?
[19:47] <cyphermox> or update the current
[19:48] <cyphermox> I'm still running desrt's branch in sbuild to make sure it's good despite what jenkins things
[19:48] <cyphermox> *thinks
[19:48] <cyphermox> it's just about done, running dh_makeshlibs
[19:53] <cyphermox> approved desrt's branch
[20:10] <seb128> cyphermox, what was the conflict?
[20:11] <seb128> cyphermox, jenkins said I forgot the commit message
[20:11] <seb128> oh, changelog, I see
[20:11] <cyphermox> ah it's good, it was saying text conflict in debian/changelog
[20:12] <seb128> cyphermox,
[20:12] <seb128> https://code.launchpad.net/~seb128/indicator-datetime/systemd-packaging-update/+merge/155585
[20:12] <seb128> updated
[20:12] <cyphermox> aye
[20:20] <cyphermox> seb128: approved, should get merged soon
[20:20] <cyphermox> release tomorrow, you know, all of that :)
[20:20] <seb128> cyphermox, thanks, I hope so, I'm uploading the other bits ;-)
[20:21] <cyphermox> hehe :)
[20:21] <seb128> they breaks on indicator-datetime << today
[20:21] <seb128> so the transition should stay in proposed until indicators land
[20:21] <cyphermox> like I said, will land tonight... should we make that go faster?
[20:21] <seb128> no, that's fine
[22:05] <seb128> cyphermox, hey again
[22:06] <seb128> cyphermox, can we get indicator-datetime to autoland?
[22:43] <seb128> cyphermox, sorry, unstable connection tonight here
[22:43] <seb128> cyphermox, can you get indicator-datetime to land?
[22:43] <seb128> I think I broke raring installability with my upload
[22:43] <seb128> the britney checks don't include ubuntu-destkop installability
[22:44] <seb128> so breaks don't block migration