[02:10] <imgbot> [03:40] <imgbot> [03:40] <imgbot> [05:42] <Mirv> hmm, if we stay on the overlay for long we need proper packaging diff:s instead of vivid <-> landing
[05:43] <Mirv> renatu: https://code.launchpad.net/~renatofilho/qtorganizer5-eds/fix-1347836/+merge/255726 needs top approval
[06:14] <Mirv> mzanetti: I'm assigning line 70 now, but you'll want to re-check it as you already landed at least the concierge_mode_workarounds branch in another landing
[06:17] <Mirv> mzanetti: and I guess you'll do line 70 before line 74 so I'm not assigning the latter
[06:32] <Mirv> (lines moved, I archived landed lines)
[07:55] <pstolowski> trainguards hello, the silo ubuntu-rtm/landing-001 is not needed anymore, you can free it
[08:00] <Mirv> pstolowski: thanks! indeed, probably none of them are needed as rtm is now "done".
[08:00] <Mirv> unless some critical hotfix will be done
[08:07] <Mirv> well, og_ra has a new rtm silo from yesterday so I guess it's not all "done" necessarily :)
[08:08] <davmor2> Mirv: if you are going to pick on ogra_ at least get his nick right so he can join in the complaining :D
[08:11] <Mirv> davmor2: I'm not picking, just mentioning, and I didn't want to highlight :)
[08:27] <mzanetti> Mirv, looking, one sec
[08:30] <sil2100> Mirv: that silo won't land even most probably, IIRC it's only to get a binary built
[08:31] <mzanetti> Mirv, ack, dropped the concierce mode branch again. no idea why it was still showing up in my queue yesterday, it's gone now
[08:31] <mzanetti> Mirv, also, ack for doing row "70" before the other (it's 51 vs 55 now)
[08:32] <Mirv> mzanetti: ack ack!
[08:36] <Mirv> mzanetti: I can reconfigure your silo if you tell me how I can get the level 25 done on MvM
[08:37] <mzanetti> Mirv, http://notyetthere.org/data2/level25.m4v
[08:37] <mzanetti> now, gimme the silo :D
[08:37] <Mirv> mzanetti: !!!!!!!! SILO RECONFIGURED AT BLAZING SPEED :D
[08:37] <mzanetti> lol. thanks Mirv
[08:38] <Mirv> lol
[08:43] <pstolowski> Mirv, hey, are you looking at landing 033 error by any chance? can I retry?
[08:45] <Mirv> pstolowski: just a moment, I was eh, reproducing a certain solution to a difficult problem
[08:45] <Mirv> mzanetti: just quickly tried that no I don't seem to get the 12$ -> 17$ in order to buy the 2nd lighthouse, but I've noticed there are some really subtle timing related stuff in MvM that I've never truly understood
[08:46] <Mirv> since I had tried the idea presented in the video before myself too
[08:46] <Mirv> mzanetti: when you post a video of it done on krillin, I'll believe ;)
[08:47] <mzanetti> Mirv, I know people have managed to do it on krillin too
[08:47] <mzanetti> Mirv, timing-related, there's an issue with the 2x button
[08:47] <mzanetti> that one has slight rounding errors
[08:48] <mzanetti> but if you only play at normal speed, it should work using the method in the video
[08:48] <Mirv> pstolowski: it claims there'd be a version clash, looking further
[08:48] <Mirv> mzanetti: I KNEW IT!! The 2X is root of all evil!
[08:48] <mzanetti> I've also managed it by placing a rocket base (upgraded to level2) in the bank at the lower right edge
[08:48] <Mirv> still, I did that try at 1X but I've noticed 2X breaks things
[08:49] <mzanetti> that one then shoots holes into the enemy row and the rest of the towers should then have enough time to deal with the rest
[08:49] <Mirv> yeah, I got to give it some (more...) time with 1X only at some point
[08:50] <pstolowski> Mirv, in click scope we have 15.04 series branch, but in the light of yesterday's discussions & emails (from sil2100, and from dobey) I'm a bit confused about where to target that MP for vivid
[08:51] <sil2100> pstolowski: I would say it's up to the project maintainers to decide, this all depends if you forsee doing any snappy development or not
[08:51] <Mirv> pstolowski: in light of yesterday's discussions the default would be that you target only 15.04, don't for, and eventually when the feature is there do a dual landing to wily+vivid later
[08:51] <Mirv> don't fork, I meant
[08:51] <sil2100> Right
[08:52] <sil2100> Well... if you really want to fork then sure, but I suppose then it means you'll have to do 2 landings always
[08:52] <Mirv> right, unity-scope-click has already forked
[08:52] <sil2100> To make sure both branches are in sync
[08:52] <Mirv> sil2100: I think you should target your 15.04 branch and note that it's really the "15.04+overlay" branch
[08:52] <sil2100> pstolowski: maybe agree with other click scope devs which branch you'll use and just target that one, you can rebase trunk on it later
[08:53] <Mirv> s/sil2100/pstolowski/
[08:53] <Mirv> pstolowski: could the "
[08:53] <Mirv> Run scope harness integration tests during build and with autopkgtest.
[08:53] <Mirv> " be landed to vivid overlay too?
[08:53] <Mirv> to get them back to sync
[08:54] <pstolowski> sil2100, Mirv I'll retarget these MPs against 15.04 branch then and have separfate MPs for trunk; that's what dobey wanted to enforce anyway
[08:55] <Mirv> mzanetti: I've to admit I cheated. I edited the config so that I'd have laserhouse instead of rocket base. I was somewhat stupid and took the two most expensive ones first. my one belief is that you can't solve level 22 (I think it was that) without laserhouse
[08:55] <mzanetti> Mirv, could be... I haven't tested that
[08:56] <Mirv> mzanetti: also extremely hard to collect starts in 20 and 21 without laserhouse, so I couldn't get enough stars to get laserhouse afterwards even though I had ~all the stars until that
[08:56] <Mirv> pstolowski: ok then
[08:56] <mzanetti> Mirv, toghether with a friend of mine we've been playing it in 5 different combinations to prove it's doable. obviously there's still risk that you run into a dead-end situation.
[08:56] <Mirv> mzanetti: on the other hand, if there'd be an option I would have "restarted" hard levels, that would have been acceptable solution for me as a player for choosing wrongly
[08:57] <sil2100> pstolowski: ok
[08:57] <mzanetti> Mirv, there is, click on the star count in the lower right corner in the level selector
[08:57] <sil2100> pstolowski: remember that in this case the bottleneck can be the number of free silos
[08:57] <Mirv> mzanetti: ...
[08:57] <mzanetti> probably a bit hidden, I agree
[08:58] <Mirv> mzanetti: :D hehe, well I'll restart at some point then. it _should_ be easy the 2nd time mostly.
[08:58] <pstolowski> Mirv, MPs in silo 33 updated; let me know if I can reconfigure
[08:58] <mzanetti> that said friend can go through the complete game in ~3 hours now
[08:58] <Mirv> pstolowski: I'd guess since the target changed it might be best I reconfigure it for you
[08:58] <Mirv> pstolowski: or anyway, I'm reconfiguring now
[08:59] <pstolowski> Mirv, k, thanks
[08:59] <mzanetti> Mirv, btw, ubuntu-app-usage | grep machines please :D
[09:00] <Mirv> mzanetti: nooooo :)
[09:00] <mzanetti> :D
[09:00] <Mirv> "enough to get notes during evenings for my absence"
[09:01] <mzanetti> :D
[09:01] <mzanetti> then a review in the store please. gotta beat Dekko again :D
[09:02] <Mirv> mzanetti: it seems nearly exactly 24h. I did try without the laserhouse, you know :)
[09:02] <mzanetti> so you still have some 7 hours left to beat davmor2
[09:02] <DanChapman> mzanetti: oi.... play fair!! ;p
[09:02] <mzanetti> lol
[09:03] <davmor2> mzanetti: now I know the flaw I've replayed it took 14hours
[09:04] <mzanetti> wow, still playing....
[09:04] <Mirv> davmor2: which flaw it was that you ran into, I remember you mentioned it?
[09:04] <davmor2> Mirv: no you have to discover it for yourself :P
[09:05] <Mirv> davmor2: darn :)
[09:05] <davmor2> mzanetti: I love it, I would use the editor thingy to add some more levels but it looks like hard work and you need some gfx skill
[09:06] <mzanetti> yeah... but afaict mivoligo is working on a second level pack. for him the hard thing is to create the json stuff
[09:06] <mzanetti> you can probably ask him to be his beta player
[09:06] <mzanetti> or even help with the json files
[09:14] <Mirv> the bot never announced that 33 was reconfigured
[09:14] <Mirv> pstolowski: I hit build for you https://ci-train.ubuntu.com/job/ubuntu-landing-033-1-build/4/console
[09:14] <pstolowski> Mirv, thanks
[09:15] <davmor2> mzanetti: you don't want me touching code if you want it to work :D
[09:15] <Mirv> pstolowski: didn't you mean to reconfigure https://code.launchpad.net/~stolowski/unity-scope-click/edit-reviews-15-04/+merge/258788 to land to the vivid branch? that MP is still on the spreadsheet.
[09:16] <mzanetti> davmor2, no code involved... it's just json files describing the level... the game code is already in place to support multiple level packs
[09:16] <davmor2> mzanetti: json is close enough to code for me to break :)
[09:27] <pstolowski> Mirv, ah, sorry, updated the MP itself, it was targeting trunk, should be touch-15.04; could you please reconfigure again?
[09:27] <Mirv> pstolowski: sure
[09:30] <Mirv> pstolowski: done
[09:31] <pstolowski> thx
[10:01] <jibel> sil2100, is there an equivalent of a -changes ML for the overlay ppa?
[10:03] <pstolowski> Mirv, weird failure in my silo 33
[10:09] <sil2100> jibel: hey, no, not really... but it's a valid point, let me think about some nice equivalent
[10:09] <sil2100> jibel: for now the closest thing is https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+builds?build_text=&build_state=all
[10:09] <sil2100> (since all upload mail goes to I-dont-know-where)
[10:10] <jibel> sil2100, that's what I use but it's difficult to read and doesn't automatically end in my inbox
[10:10] <Mirv> pstolowski: I understand what it says but not why it says that. could you try once more and we see if it's somethig temporary? there are errors before that bzr ERROR line which could have cause it.
[10:11] <kalikiana> cihelp ping, https://jenkins.qa.ubuntu.com/job/ubuntu-sdk-team-ubuntu-ui-toolkit-staging-vivid-i386-ci/477/testReport/ can somebody investigate this bogus failure? it's happening in more than one branch reliably now
[10:11] <Mirv> pstolowski: oh, wait, it's the credentials one, checking that still
[10:12] <sil2100> jibel: I'm pretty sure we can get something better, just need slangasek to pop up
[10:13] <sil2100> jibel: probably we could somehow redirect all the upload mail somewhere or something
[10:14] <Mirv> pstolowski: ok, the ubuntuone-credentials branch is simply broken, it adds its own changelog entry. that wouldn't be a problem necessarily, but the version number is also of wrong format.
[10:15] <t1mp> kalikiana: is https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/newJsonApiCheck/+merge/235830 ready for landing?
[10:15] <t1mp> besides the CI issues
[10:16] <kalikiana> t1mp: yep
[10:16] <t1mp> kalikiana: ok. I'll happrove it when the CI issue is cleared up
[10:16] <Mirv> pstolowski: is the usage of native version numbers intentional? if so, you should continue doing that by dropping the "-0ubuntu1" from the MP
[10:17] <kalikiana> t1mp: btw I made a merge commit to https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/oldAppHeaderMoving/+merge/258617 so you'll need to re-approve… trying to see if it helps at all with the bogus failures
[10:17] <t1mp> kalikiana: actually, I happrove https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/newJsonApiCheck/+merge/235830 now
[10:17] <t1mp> let's see what cI does
[10:18] <kalikiana> t1mp: cool
[10:18] <t1mp> kalikiana: happroved oldAppHeaderMoving as well
[10:19] <Mirv> pstolowski: it seems ubuntuone-credentials has always used native (no "-0ubuntuN"). it doesn't really matter after all which is it, but note that we do consider Canonical projects as "Canonical upstream" projects, in which case the Ubuntu packaginng is not "Ubuntu's" and therefore 95% of our projects do have the ubuntu versioning. if you want to switch to the same, you'd keep the changelog entry as is but do bzr rm debian/source
[10:21] <Mirv> I mean, in which case the packaging is Ubuntu-the-project's packaging of Canonical upstream sources, so it's noted like that, having the ubuntu versioning instead of claiming the package would be Ubuntu-the-project's internal package
[10:22] <pstolowski> Mirv, ok, I didn't know of these subtleties; trying to fix the changelog entry
[10:34] <davmor2> popey: reminders has one small design issue other than that clean bill of health and passed
[10:36] <sil2100> Yaay!
[10:47] <davmor2> popey: design issue for you https://bugs.launchpad.net/reminders-app/+bug/1454198
[10:58] <t1mp> kalikiana: https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/trunkSync/+merge/258777 failed on autolanding
[10:59] <t1mp> kalikiana: ASSERT failure in QTest::fetchData(): "Test data requested, but no testdata available.", file qtestcase.cpp, line 2044
[10:59] <t1mp>   
[10:59] <t1mp> cihelp: ping^
[11:00] <psivaa> t1mp: kalikiana: we'll take a look at it
[12:19] <sil2100> o/
[12:23] <pmcgowan> plars, how many devices to we have in the ci setup
[12:30] <pmcgowan> or fginther ^^
[12:43] <sil2100> mzanetti: assigned a silo for you, just remember you have another unity8 silo in silo 33
[12:43] <mzanetti> sil2100, thanks, yep, I'm aware of that
[13:04] <fginther> pmcgowan, can you be more specific? which kind of device and for what use?
[13:06] <plars> pmcgowan: hi
[13:06] <pmcgowan> phones for auto testing
[13:07] <pmcgowan> like krillin and nexus 4
[13:07] <pmcgowan> fginther, or plars
[13:07] <plars> pmcgowan: do you mean for smoke testing? or merge proposals? boot testing? - it's not always one big shared pool
[13:08] <pmcgowan> yes :)
[13:08] <fginther> or just total devices :-)
[13:08] <plars> heh, ok, one moment
[13:09] <boiko> jibel: regarding silo 24, jenkins has been flaky for telephony-service, it runs the unit tests twice for each job, once using dh_auto_test (which passes) and the other one I don't know exactly how it is called
[13:09] <boiko> jibel: but the first run always passes
[13:09] <plars> pmcgowan: so for mako, we have about 24 at the moment, though some of them are basically broken to the point of being doorstops
[13:11] <plars> pmcgowan: for krillin, there are 10 at the moment, but not all are instrumented yet, so we can't automatically recover all of them if they get in a bad state. I've heard there are 4 more, but IS was waiting to hook those up, and instrument the others until the rack move, that just happened recently
[13:12] <plars> pmcgowan: if you can help me understand exactly what information you're looking for, I may be able to email you something a little more helpful
[13:12] <plars> pmcgowan: unless that already gives you what you are looking for?
[13:12] <pmcgowan> plars, I wanted a round number to get an idea how many are required for decent coverage
[13:12] <pmcgowan> sounds like 10
[13:22] <plars> pmcgowan: it depends a lot on the types of testing you want to do, number of channels you want to test, and how quickly you want the results
[13:23] <plars> pmcgowan: with a little padding of course because sometimes good devices go bad
[13:24] <plars> relatively uncommon, but good to plan in there because murphy strikes hardest when you assume all will go well :)
[13:29] <pmcgowan> plars, thanks
[13:38] <kenvandine> trainguards:  I need to sync a couple packages from the overlay ppa to wily, how do i create a silo for that?
[13:41] <plars> kalikiana: hi, I'm looking at the job you mentioned earlier. I'm thinking that might be related to it not using the overlay ppa for vivid?
[13:42] <kalikiana> plars: I wouldn't know how that affects it. it used to work and suddenly all branches fail in this way
[13:42] <kalikiana> there has been no change here that I'm aware of
[13:44] <kalikiana> Mirv: if you happen to know if there was any change that I missed ^^
[13:47] <plars> kalikiana: I also notice that it seems to complain of missing test data? Is there any chance it's trying to pull that from an external source?
[13:47] <barry> sil2100: hi.  did that patch land?  can i retry my build?
[13:54] <sil2100> barry: hey! Ah, it landed but I need to ask IS to redeploy the train
[13:54] <sil2100> Let me do that, sorry, it slipped my mind
[13:56] <kalikiana> plars: not "also" that IS the problem :-)
[14:06] <barry> sil2100: no worries, thanks!
[14:06] <kenvandine> sil2100,  I need to sync a couple packages from the overlay ppa to wily, how do i create a silo for that?
[14:07] <Laney> kenvandine: can't you just copy-package them like I gave the line for in #ubuntu-desktop?
[14:07] <Laney> or do they really need rebuilding for something?
[14:07] <kenvandine> sure... that would work
[14:07] <sil2100> kenvandine: in this case copy-package is still a valid solution I guess :)
[14:07] <kenvandine> but i wanted to make sure we shouldn't do somethign else
[14:07] <kenvandine> sil2100, ok, i can do that
[14:07] <sil2100> The tools are not ready yet to make things easier for people
[14:07] <kenvandine> ok
[14:07] <sil2100> We learned about all the plans too late...
[14:10] <Laney> It's easy enough to do individually for core-devs, but I suppose you might want a view of the whole state so things don't get lost.
[14:11] <oSoMoN> trainguards: hey, can I have a silo for line 62, please?
[14:15] <pmcgowan> sil2100, per the point raised above, has a full sync of the ppa to wily been discussed or planned
[14:20] <barry> oSoMoN: done
[14:25] <oSoMoN_> barry, thanks!
[14:28] <kenvandine> pmcgowan, even after a full sync, we really need landings to automatically go to wily and the overlay, to prevent this in the future
[14:30] <pmcgowan> kenvandine, agreed, seems the topic of the year
[14:30] <pmcgowan> I pretty much agree with the comments on the thread, we need to land to trunk and be prepared to have two branches when necessary
[14:30] <kenvandine> nobody wants to relive the utopic/rtm landings again
[14:31] <pmcgowan> we have to land both places imo but need to sort out the overhead
[14:31] <pmcgowan> same ole topic
[14:33] <plars> kalikiana: ok, so if the problem is that it's trying to pull external test data, that may not be something we can accommodate now. Any other way to get test data in that it needs?
[14:33] <plars> kalikiana: the short story is that it's "accidentally" worked for a while, but shouldn't have been working
[14:41] <sil2100> pmcgowan: hey! :)
[14:41] <sil2100> pmcgowan: yeah, actually, slangasek did that just now
[14:43] <sil2100> pmcgowan: I poked slangasek earlier about that and he just did it
[14:43] <sil2100> Swiftly ;)
[14:43] <sil2100> kenvandine: yeah, we're working on the dual-landing stuff, but we just started ;/
[14:43] <sil2100> barry: hey! Try rebuilding, the fix should be deployed by IS now
[14:44] <barry> sil2100: \o/
[14:45] <slangasek> yes, that's only a one-time sync of the stuff currently in the overlay however
[14:45] <kenvandine> slangasek, thanks!
[15:01] <kalikiana> plars: what does that mean, cannot accomodate it now? if you know about some changes behind the scenes you'll need to tell me because as I said nothing changed in the ui toolkit
[15:03] <kalikiana> plars: and it's slightly urgent if I may add because nothing whatsoever passes right now
[15:15] <sil2100> barry: hmm, I wonder why the package didn't get uploaded to the PPA
[15:15] <barry> sil2100: good question!
[15:16] <sil2100> It looked as if it didn't generate a tarball
[15:17] <barry> sil2100: i don't see any errors in the console logs
[15:18] <barry> sil2100: where do we go from here?
[15:20] <plars> kalikiana: if the test is dependent on external access, can you give me details on what it's trying to do? and why?
[15:20] <sil2100> barry: one moment, need to finish the meeting and I'll try to check what happened
[15:21] <kalikiana> plars: the benchmark test is just loading tons of compoennts, nothing more
[15:21] <barry> sil2100: cool, thx
[15:22] <plars> kalikiana: details? what external servers does it want to connect to? are the connections inbound or outbound? how is it communicating with them? what ports/protocols? what is the purpose of connecting to them? can it be done in another way that doesn't depend on external resources (which can by definition be fragile)
[15:22] <kalikiana> plars: huh? there's no servers involved, it's just loading .qml components
[15:23] <plars> kalikiana: ok, so let's back up... it sounded to me like it was trying to pull test data from [somewhere outside the lab], and when I asked about it, it sounded like you were saying that is indeed the case. Perhaps I misunderstood?
[15:24] <plars> kalikiana: I don't know what your code there is doing, I could use your help with that :)
[15:24] <kalikiana> plars: when I say loading components that means grabbing .qml files from the build folder
[15:24] <kalikiana> and creating objects for them in a loop
[15:25] <kalikiana> plars: and that test hasn't changed in eons really
[15:27] <kalikiana> plars: it could only legitimately fail - that I can see - if somehow the build folder was removed during the build
[15:28] <kalikiana> plars: hmmmm not sure if that will help, but I got an idea that I could add a line to double-check if anything about that build folder changed, if I let that run on ci
[15:28] <kalikiana> so at least one could see if there was any unexpected differences in the build itself
[15:29] <plars> kalikiana: it looks like a great number of tests in there pass too though, do those not depend on loading things from the build dir?
[15:32] <plars> kalikiana: it looks like perhaps it failed ever since https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/separate-uitk-versions/+merge/257455 - which was merged anyway. Can you take a look at that MP?
[15:33] <kalikiana> plars: they do… it seems the benchmark test is the only instance of using the build folder defined at build time rather than relying on environment variables
[15:34] <kalikiana> and tst_components_benchmark: QDEBUG : tst_components_benchmark::benchmark_creation_components() Found 0 tests. suggests that build folder is either empty or wrong
[15:34] <kalikiana> I'm checking now what other tests do… maybe this makes sense to change if it's not reliable
[15:35] <kalikiana> so it might be that it was a "happens to work" kind of approach; hold on
[15:35] <plars> kalikiana: actually.. it may have failed even farther back, looking
[15:38] <plars> kalikiana: ah, it failed as far back as build 463, which also tested that same MP. So I would think that MP I mentioned earlier is suspect
[15:40] <kalikiana> plars: hmmmm
[15:42] <kalikiana> plars: actually, that could make a lot of since given that branch did change the directory structure. even though I don't see that error in the test results of it
[15:42] <kalikiana> +sense
[15:45] <sil2100> barry: phew, only now I finished
[15:46] <sil2100> Let me take a look wth happened
[15:47] <rvr> kenvandine: ping
[15:50] <barry> sil2100: thx.  i'd like to break for lunch soon, but i'll stick around for a little bit longer to see what happened
[15:55] <kenvandine> rvr pong
[15:56] <sil2100> barry: so, I know why it didn't appear in the PPA
[15:56] <sil2100> barry: but the root cause of the issue is still unknown
[15:57] <sil2100> AH!
[15:57] <sil2100> barry: I think I know what's up :)
[15:57] <barry> sil2100: i hope it's soemthing i broke.  i like breaking things :)
[15:58] <sil2100> barry: in your MP, the debian/changelog top-entry needs to be UNRELEASED - because you switched it to 'wily', the train actually thought it's already released and probably created a new entry on top of it
[15:59] <sil2100> barry: so the builder went like 'ok, 3.0 got already released, so I won't include the tarball in the upload'
[15:59] <davmor2> barry: man you spend one week with QA and you think it's your job to break things ;)
[16:01] <barry> sil2100: i'll resubmit with UNRELEASED
[16:01] <barry> davmor2: :)
[16:01] <barry> sil2100: i actually originally had that, then did a test build in my ppa and forgot to undo that change
[16:03] <sil2100> barry: excellent :)
[16:04] <rvr> kenvandine: Silo 31
[16:05] <rvr> kenvandine: I installed your click package, but I can't see it the dash
[16:05] <barry> sil2100: mp updated.
[16:05] <kenvandine> hummm
[16:06] <sil2100> barry: rebuild and let's get this finally working :)
[16:06] <kenvandine> rvr trying doing a search for it
[16:06] <kenvandine> maybe there's a click scope bug?
[16:06] <barry> sil2100: +1
[16:09] <rvr> kenvandine: That worked
[16:09] <kenvandine> rvr, :/
[16:10] <rvr> kenvandine: There are not applications to share with
[16:10] <barry> sil2100: let's let this run.  /me -> lunch
[16:10] <barry> sil2100: thanks
[16:10] <sil2100> barry: have fun! :)
[16:34] <john-mcaleely> davmor2, is there a bug for video playback being 'all black' on krillin/vivid?
[16:34] <davmor2> john-mcaleely: there is for a video that you record
[16:35] <john-mcaleely> davmor2, yeah, that one then
[16:35] <john-mcaleely> do you know where to look for it?
[16:35] <davmor2> john-mcaleely: one second
[16:35] <rvr> jhodapp: ping
[16:36] <davmor2> john-mcaleely: https://bugs.launchpad.net/bugs/1451816
[16:36] <john-mcaleely> davmor2, perfect, thank you
[17:18] <slangasek> sil2100: hi, so it appears that the ubuntu-touch/vivid-proposed channel has been updated in the config to point at /srv/cdimage.ubuntu.com/www/full/ubuntu-touch/vivid/daily-preinstalled now - is this your doing?
[17:19] <slangasek> sil2100: (in the absence of a VCS for etc/config, I think it would be a good idea to send email whenever making changes to the config of existing channels in this file...)
[17:19] <sil2100> slangasek: hey! Yes, since we wanted to continue having vivid-overlay based images in devel after the cdimage server switched focus to wily
[17:19] <boiko> Ursinha: regarding silo 24, telephony-service CI job has been flaky for quite some time now, I was actually surprised it passed once in that MR. Who should I talk to regarding those failures? I also have CI job problems for dialer and messaging
[17:20] <sil2100> slangasek: sorry, I'll make sure to send out an announcement, I only informed ogra_ and rsalveti about that...
[17:20] <slangasek> sil2100: ok; so as you and I discussed, the current stable overlay is really the wrong place for "devel" to happen, it's intended to be rc-proposed
[17:21] <slangasek> sil2100: based on pmcgowan's mail today we're done with rtm/14.09 now, right?  So we can point rc-proposed at vivid+stable-overlay now?
[17:21] <sil2100> slangasek: sure thing, right, when I did the change there was still a lot of questionmarks
[17:21] <sil2100> slangasek: I suppose we can :)
[17:25] <Ursinha> boiko: not sure you have seen my last comment in there, jibel says that the fact tests pass in the first run and not in the following might mean they are corrupting the testbed, and could be a problem in the tests instead of the infrastructure
[17:25] <Ursinha> boiko: you might want to rule that out
[17:26] <jhodapp> rvr, pong
[17:26] <Ursinha> boiko: but if you have other examples of jobs being flaky, please bring them to cihelp and we'll have a look
[17:26] <boiko> Ursinha: I replied to that one: I run them multiple times on desktop, chromebook and on the device, and they always pass
[17:26] <boiko> Ursinha: and jenkins does not spit out the test logs of the second test run, not sure how it runs them (the dh_auto_test is prepared to log the failures on telephony-service)
[17:27] <Ursinha> boiko: that is useful information, let me check with current CI vanguard today so we can have a look
[17:28] <rvr> jhodapp: Hey, silo 22 (media-hub) is blocked because the merge proposal is not reviewed and approved.
[17:28] <plars> Ursinha: that would be me, do you have some background on this?
[17:28] <jhodapp> rvr, you can't test it before review?
[17:28] <Ursinha> plars: so, it all started with this: https://trello.com/c/TBw1oCqb/1665-ubuntu-landing-024-telephony-service-boiko
[17:29] <rvr> jhodapp: ...
[17:29] <Ursinha> plars: CI is failing for telephony-service, the testsuite runs a couple of times and fails in the second run, almost like testbed is corrupted by first run
[17:29] <Ursinha> plars: boiko is the owner, he will have more details
[17:29] <rvr> jhodapp: If code hasn't been reviewed and approved is not ready for QA.
[17:30] <rvr> jhodapp: What if the reviewer asks for a change?
[17:30] <boiko> plars: is there a way to mimic the jenkins setup locally? I want to understand why some tests are failing on the second run
[17:30] <jhodapp> rvr, agreed in general but this is a very trivial change...I'll get someone to take a quick look
[17:31] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20150511-3912934.tar.xz
[17:31] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-testresults-20150511-3912934.ods
[17:31] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20150511-3912934.changes
[17:31] <john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150512-c5df9c0.tar.xz
[17:31] <john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-testresults-20150512-c5df9c0.ods
[17:31] <john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150512-c5df9c0.changes
[17:31] <john-mcaleely> sil2100, jibel device tarballs for krillin ^
[17:34] <plars> boiko: give me a minute to look at it all, sorry this is my first time to look at this particular problem so I need to catch up
[17:36] <plars> boiko: just to ensure I'm looking at the right thing, can you point me at the most recent failing job?
[17:37] <boiko> plars: let me see
[17:38] <boiko> plars: https://jenkins.qa.ubuntu.com/job/telephony-service-ci/439/
[17:40] <boiko> plars: so, it seems jenkins run dh_auto_test and then later it calls make test, is that correct?
[17:41] <fginther> plars, boiko, this might be the case that the B10gcovr_run hook that is running the second pass of the tests is no longer needed
[17:42] <fginther> AIRC, that hook was used to force packages to run tests that were not setup to do so by dh_auto_test. If the tests are already being run, there's no reason to run them twice
[17:42] <Ursinha> fginther: is there a way to identify and fix these before they fail?
[17:45] <fginther> Ursinha, we could filter the list to the projects using B10gcovr_run and review which ones are doing 2 builds be reviewing the build output.
[17:46] <fginther> Ursinha, that's not all that efficient, I can't think of another way at the moment
[17:48] <plars> fginther: we could test that by rekicking this job a few times without the gcovr_run hook right?
[17:48] <fginther> Ursinha, plars, boiko, it's also possible that without B10gcovr_run, this project will stop producing code coverage results. it all depends on this projects make files
[17:49] <fginther> plars, yes: http://s-jenkins.ubuntu-ci:8080/job/telephony-service-vivid-amd64-ci/
[17:49] <fginther> err, this one: http://s-jenkins.ubuntu-ci:8080/job/telephony-service-vivid-amd64-ci/109/
[17:49] <fginther> plars, in order to test that, we have to retrigger the $release-$arch sub job and modify the "builder_hooks" parameter
[17:49] <plars> fginther: am I safe to assume that I need to take out all the gcovr related hooks? or just gcovr_run?
[17:50] <plars> oh, I can't just retrigger this one as a test?
[17:50] <boiko> fginther: so, as long as CMAKE_BUILD_TYPE=coverage, telephony-service will generate those
[17:50] <fginther> plars, just gcovr_run. The others are needed to other gcover dependencies
[17:52] <fginther> H10enable_coverage is the one that sets "CMAKE_BUILD_TYPE=coverage", so this experiment *should* work
[17:55] <boiko> fginther: plars: now that you are at it, we have been having failures on dialer-app jenkins jobs too, for instance: https://jenkins.qa.ubuntu.com/job/dialer-app-ci/560/
[17:56] <fginther> plars, the basic symptom of this problem is that the package's tests are executed twice. That's not something that apt packages are expected to support so the second run could fail because the first run leaves things in a non-pristine environment
[17:56] <boiko> fginther: plars: otto builds are failing for messaging-app too: https://jenkins.qa.ubuntu.com/job/messaging-app-ci/557/
[17:57] <plars> boiko: otto builds are known to be broken right now
[17:57] <boiko> plars: ah ok, so just the dialer one remains
[17:57] <Ursinha> plars: should we add that disclaimer to the channel topic?
[17:57] <boiko> Ursinha: might be a good idea
[17:58] <boiko> Ursinha: is there a global switch that could be used to turn otto builds off until they are fixed?
[17:58] <fginther> boiko, we're in the process of removing the otto tests for most projects, We some agreement a while back that these were not that helpful and had just postponed removing them until the failed hard
[17:58] <Ursinha> boiko: I wouldn't think so, but fginther has all answers and might prove me wrong
[17:58] <Ursinha> hehe
[17:59] <barry> sil2100: \o/  it built
[17:59] <boiko> Ursinha: :)
[17:59] <fginther> boiko, the touch tests on a device will remain
[17:59] <plars> fginther: looks like http://s-jenkins.ubuntu-ci:8080/job/telephony-service-vivid-amd64-ci/109/console passed
[18:00] <boiko> fginther: the only think nice about otto tests is that they produce videos of the failures, but I agree: most of the time the failures were on otto itself rather than the tests actually failing
[18:00] <boiko> fginther: plars: I'll be away for ~1 hour, but I will read the backlog once I'm back, thanks for the help
[18:01] <fginther> plars, the build passed, but there was no coverage output... I noticed that the B09googletests hook is running the tests the first time, trying again with that removed but B10gcovr_run added back in
[18:02] <fginther> http://s-jenkins.ubuntu-ci:8080/job/telephony-service-vivid-amd64-ci/110/
[18:02] <plars> googletests?
[18:02] <fginther> plars, I think they run gtests, which was a google project
[18:02] <fginther> or something like that. My memory of some of these things is starting to fade :-(
[18:05] <boiko> fginther: plars: telephony-service uses QTest, not gtests
[18:12] <plars> fginther: boiko: that one seems to have passed and produced coverage results
[18:16] <fginther> plars, that looks better. I'd give boiko a chance to comment, but I think that's probably the best fix we have
[18:24] <plars> fginther: so iiuc, I'll need to add hooks line for that in stacks/head/phone.cfg that includes everything in the globally specified hooks except the B09googletests one right?
[18:25] <fginther> plars, correct
[18:32] <plars> fginther: https://code.launchpad.net/~pwlars/cupstream2distro-config/telephony-remove-googletests/+merge/258919 - but I'll be sure to get boiko to take a look at the results and make sure they're sane before top approving if you ack the mp
[18:35] <fginther> plars, approved, thanks
[19:25] <sil2100> cyphermox: ^
[19:25] <sil2100> cyphermox: is that ok? ^
[19:25] <cyphermox> I think so, but guess I should triple-check
[19:27] <cyphermox> yes, it's good
[19:27] <cyphermox> I included those already
[19:34] <sil2100> cyphermox: ok, publishing then
[19:36] <cyphermox> ah, that's something new
[19:36] <sil2100> No worries ;)
[19:36] <cyphermox> mmkay
[19:36] <sil2100> You're LP name is different, I forgot about that
[19:36] <sil2100> *Your
[19:36] <sil2100> Ok, I EOD now
[19:36] <sil2100> o/
[19:37] <slangasek> ogra_: what was the reason for this version number? https://launchpad.net/ubuntu/+source/ubuntu-touch-meta/1.221vivid1
[19:52] <boiko> plars: on the MP I don't see the succeeded telephony-service CI job, do you have the link handy?
[19:53] <plars> boiko: http://s-jenkins.ubuntu-ci:8080/job/telephony-service-vivid-amd64-ci/110/
[19:55] <boiko> plars: that looks good, thanks for looking into that
[20:29] <kalikiana> plars: FYI I know how to deal with the benchmark test now, a fix is in progress. thanks a lot for helping me narrow it down
[20:29] <plars> kalikiana: happy to help :)
[20:50] <tedg> thomi, Would it be possible to just have projects that have a "15.10" series land that on wily and then do CI on their "15.04" series on vivid?
[20:51] <tedg> thomi, Complex naming, I realize, but I think it could make things easier for everyone.
[20:52] <thomi> tedg: in an alternate universe, where we can coordinate that number of projects, yes. :D
[20:53] <tedg> thomi, Make it a requirement, people will conform :-)
[20:53] <thomi> in this universe, everyone is a unique snowflake, and gets to configure things how they like
[20:53] <thomi> lol
[20:53] <thomi> for next time maybe
[20:54] <tedg> thomi, Start now or it'll never happen :-)
[20:54] <tedg> Perhaps require a "ci-config.json" in the root directory where people put "snowflake things" or else you get the default.
[20:54] <thomi> tedg: this is the path of least resistance for us, and we're trying to get this done quickly
[20:55] <thomi> if you're worried at the overhead of filling in the spreadsheet, let's talk about that :D
[20:55] <tedg> A spreadsheet is never the path of least resistance.
[20:56] <tedg> Duplicating the lines is going to be a PITA.
[20:56] <thomi> I don't think there's that many projects that already have dual landing set up
[20:57] <thomi> I mean, branches for dual landing set up
[20:57] <tedg> All mine do :-)
[20:57] <tedg> https://launchpad.net/ubuntu-menu-bar/
[20:57] <tedg> They have for several distro releases.
[20:58] <tedg> I have a script that generates karma^W^W configures the new branches
[20:58] <thomi> tedg: should be easy to make your script spit out the values you need to append to the SS, no?
[20:59] <tedg> thomi, If you tell me what you want, or I can just give you the script to generate what you need. It's lp:$(project name)/15.10 and lp:$(project name)/15.04
[21:00] <thomi> tedg: I need that, in the spreadsheet, along with what they land to in the second column
[21:00] <tedg> thomi, for example: https://launchpad.net/indicator-messages/+series
[21:05] <tedg> thomi, http://paste.ubuntu.com/11102042/
[21:05] <fginther> tedg, it sounds like .... nice
[21:08] <fginther> tedg, that looks like it should work. Is it safe to assume that the 13.10 branches all alias the trunk branch?
[21:08] <tedg> fginther, No, but the 15.10 ones do :-)
[21:09] <fginther> tedg, ohh, I was looking at https://code.launchpad.net/appmenu-gtk and turned my brain off :-)
[21:09] <tedg> fginther, More importantly for you guys, I think if they don't work, I'm fine with CI not working until I fix them.
[21:19] <fginther> kenvandine, is lp:friends-app still a thing?