[02:10] <imgbot> [03:30] <imgbot> [03:30] <imgbot> [06:21] <Mirv> cjwatson: thanks for sharing. it's true that everyone takes granted all the huge speedups that have already been made. I can't remember anymore the 20 hour armhf builds :)
[07:17] <balloons> fginther, 4 more apps to turn on pep8/pyflakes. This should be everything; stock-ticker-mobile-app
[07:17] <balloons> rss reader
[07:17] <balloons> terminal
[07:17] <balloons> ubuntu-docviewer-app
[07:19] <balloons> fginther, also, as I mentioned yesterday, not sure if you saw, rss reader jenkins is approving merges where tests fail
[07:20] <fginther> balloons, let me look at the rss issue
[07:24] <fginther> balloons, the rssreader landing with failing tests is intentional. When the tests were first added to ci, they weren't passing, we wanted the feedback, but not to block landing until the tests could be fixed. Are we now in a position to block landings and fix the tests? If so, I'll switch them to block.
[07:24] <balloons> fginther, are any other tests not set on block atm?
[07:25] <balloons> fginther, interesting we never switched them on :-)
[07:26] <fginther> balloons, rssreader is the only one
[07:28] <balloons> fginther, ok, I think it's fine to switch it back on. I'll have a look to make sure it's passing in trunk
[07:45] <fginther> balloons, can you review please? https://code.launchpad.net/~fginther/cupstream2distro-config/coreapps-pep8-2/+merge/220382
[07:47] <fginther> cjwatson, we've put together a plan while here in Malta for doing autopkgtest with click packages. Are you interested in more details?
[07:53] <mhr3> is the spreadsheet broken again?
[07:56] <Mirv> mhr3: in which way?
[07:56] <mhr3> resumed from suspend and the page didn't update
[07:57] <mhr3> but after refresh it's looking ok
[07:57] <mhr3> let's call it chrome bug
[08:02] <cjwatson> fginther: sure, though hopefully it doesn't require changing click itself (except maybe docs)
[08:04] <sil2100> Phew
[08:04] <fginther> cjwatson, no, the click package itself isn't be changed to run the tests. The general idea is to add a file 'click/tests/control' in the source tree that adt-run will interpret and perform the right magic
[08:05] <fginther> cjwatson, it will basically mirror the format used by autopkgtest for debian tests
[08:09] <balloons> fginther, approved
[08:15] <cjwatson> fginther: Having a click/ prefix there is odd given that there's no existing click/ directory, unlike for Debian packages where debian/ already exists.  How about just tests/control?
[08:16] <cjwatson> fginther: How will you find the source tree for a given click package?  A manifest key or something?
[08:16] <cjwatson> fginther: (And the right version of that source tree, too)
[08:20] <jhodapp> sil2100, can I get a silo for https://code.launchpad.net/~jhodapp/media-hub/gallery_trusted/+merge/220386 please?
[08:20] <sil2100> jhodapp: looking
[08:21] <jhodapp> k
[08:21] <fginther> cjwatson, there is already a click/ directory. Also, this will use a bzr revid in the click manifest to reference the test source. sergiusens has some more details on this
[08:21] <cjwatson> fginther: Not conventionally there isn't
[08:22] <cjwatson> bzr> ok
[08:22] <cjwatson> fginther: I mean, you might find it in one or two packages, but it's not part of the format or anything
[08:22] <fginther> cjwatson, I see. Our assumption was that is was a common thing
[08:22] <sil2100> jhodapp: ok, I see you're CI-train enabled - would you like to add the landing request yourself? It will take up to a few minutes, and then you won't have to ask for that anymore
[08:23] <jhodapp> sil2100, I am yes, though I've not done that before...anything special I need to know?
[08:23] <cjwatson> fginther: The only part of the source tree that's at all implied by click itself is the manifest.json file (even that has an overrideable location, although I'm guessing most people don't bother)
[08:24] <sil2100> jhodapp: just go to http://wiki.ubuntu.com/citrain/ add a new row and fill out these fields: Description (of the landing), lander (enter your name), test plan (enter a test plan or a link to the test plan) and then Merge propolsals to land
[08:24] <jhodapp> sil2100, easy enough, thanks
[08:24] <sil2100> jhodapp: after those fields are filled, go to column 'Ready?' and set it to Yes
[08:25] <sil2100> jhodapp: we'll get a ping automatically once a landing is set to ready :)
[08:25] <jhodapp> perfect
[08:27] <sil2100> Laney: I published for you ;)
[08:27] <sil2100> Laney: (forgot you had the power)
[08:27] <Laney> oh
[08:27] <Laney> thanks!
[08:27] <sil2100> Laney: no worries, I set you as the 'publisher' ;)
[08:29] <dednick> sil2100: hi. did you get my message about unity-mir-devel-ci yesterday?
[08:29] <sil2100> dednick: hi! hm, I probably missed it - what's up?
[08:30] <dednick> sil2100: we think it should be including mir staging ppa. otherwise it's just building against mir trunk releases rather than mir/devel.
[08:32] <jhodapp> sil2100, I got pinged by the ci-train bot, will it create the silo automatically and build it now?
[08:33] <sil2100> jhodapp: I will now assign a silo for you - once that's done, you'll get pinged and you will be able to build stuff in your silo :)
[08:33] <jhodapp> sil2100, perfect thanks
[08:35] <kenvandine> sil2100, the abi fix for content-hub is proposed
[08:37] <ogra_> Wellark, how is the work on the .crash going ?
[08:37] <ogra_> Wellark, given it shows up on every dialer-app test it should be very easy to reproduce it locally so you can gather the backtrace on your phone
[08:42] <bfiller> sil2100: can we have a silo for line 38 please (content-hub fix)
[08:42] <sil2100> bfiller, kenvandine: thanks guys! Will assign, now in a meeting so things are slower ;)
[08:48] <sil2100> bfiller, kenvandine: it's assigned and ready for action
[08:48] <bfiller> sil2100: thanks
[08:48] <kenvandine> awesome
[08:54] <sergiusens> fginther:  cjwatson: the click directory in the projects is just a convention and not stuck on stone, it could be anything really; I'm not sure we should tie this to the click spec proper even
[09:00] <cjwatson> sergiusens: It seems weird to me to have a click directory in app source trees at all
[09:00] <cjwatson> And certainly if it's only for autopkgtests
[09:01] <sergiusens> cjwatson: it was more for click specific build artifacts, to keep the cmake rules separated
[09:02] <cjwatson> OK; but I expect lots of autopkgtests will be in native packages that don't need anything like cmake rules anyway
[09:02] <cjwatson> Er, QML packages, not native packages
[09:02] <Mirv> sil2100: hey sorry I lost now this morning's sessions, I had a session here and lost track of time
[09:03] <cjwatson> So, well, I mean I've tried to stay out of defining a source package layout in general, but I do think it's worth thinking about keeping it simple when complexity isn't required
[09:06] <dednick> sil2100: is applying the mir staging ppa an option for the unity-mir-devel CI?
[09:06] <sil2100> dednick: ok, so, after the meetings now
[09:06] <sergiusens> cjwatson: yeah, that's true
[09:06] <sil2100> dednick: I think you'll have to poke vila about that I guess
[09:07] <dednick> sil2100: ok. thanks.
[09:07] <sil2100> dednick: since I'm only managing ci-train ;)
[09:07] <sil2100> Mirv: no worries! Indeed I thought you might be in some sessions now
[09:10] <vila> dednick: do you have the url for the CI job ? (I suspect that will end up on fginther plate but I can have a look first)
[09:11] <dednick> vila: https://jenkins.qa.ubuntu.com/job/unity-mir-devel-ci/10/
[09:13] <vila> dednick: right, so http://s-jenkins.ubuntu-ci:8080/job/unity-mir-devel-ci/ internally
[09:22] <vila> dednick: the mir staging ppa is http://ppa.launchpad.net/mir-team/staging/ubuntu ?
[09:23] <dednick> vila: er... yes? https://launchpad.net/~mir-team/+archive/staging
[09:23] <vila> dednick: yeah, sorry, apt syntax ;)
[09:23] <bzoltan> sil2100: I would need a Silo for the line 39
[09:23] <bzoltan> sil2100: sorry for being pushy :)
[09:24] <sil2100> ;)
[09:24] <vila> fginther: I suspect dednick wants something like adding D09add_ppa-mir-team-staging to the unit-mir-devel-ci jobs but I can't find them in cu2d-config stacks...
[09:25] <sil2100> bzoltan: assigning!
[09:26] <vila> fginther: bah, silly, stacks/head/unity8.cfg ? Or is it ./stacks/no-dailies/mir.cfg instead ?
[09:28] <vila> fginther: something like https://pastebin.canonical.com/110519/ ?
[09:31] <fginther> vila, sorry, in a meeting
[09:31] <fginther> vila, looking now
[09:31] <vila> fginther: no worries
[09:34] <davmor2> did I miss the landing team meeting?
[09:34] <mandel> sil2100, hello! I have noticed your comment about the platform-api work
[09:35] <fginther> vila, the devel jobs are under ./stacks/no-dailies/mir.cfg
[09:36] <fginther> vila, the proper notation for the hook is D09add_ppa~mir-team~staging
[09:38] <davmor2> sil2100: did I miss the landing team meeting?
[09:38] <vila> fginther: ack, with that change, should I just file a MP ?
[09:38] <vila> davmor2: you weren't there as far as I could see ;)
[09:39] <davmor2> but it's now surely I just got a ping for it
[09:42] <sil2100> davmor2: yeah ;) We'll have a dogfooding request for you later during the afternoon
[09:43] <davmor2> sil2100: when did it happen so I can make sure my calendar is in sync
[09:51] <vila> fginther: when you can, https://code.launchpad.net/~vila/cupstream2distro-config/add-staging-ppa-to-mir-devel/+merge/220413 (will search the playbook for the next steps ;)
[09:52] <vila> fginther: which seems to be https://wiki.canonical.com/UbuntuEngineering/CI/Playbook/UpstreamMerger#Updating_job_configurations
[10:03] <fginther> vila, I added a comment. '~' is used as a separator between the team name and the ppa name.
[10:05] <vila> fginther: ha damn, bad eyes ;)
[10:06] <vila> fginther: fixed
[10:08] <fginther> vila, approved, and yes, the job http://s-jenkins.ubuntu-ci:8080/job/deploy-cupstream2distro-config/ is used to update the configurations once the MP has merged
[10:10] <fginther> balloons, FYI the coreapps updates have been deployed to jenkins
[10:12] <vila> fginther: \o/ finally ! I thought I'll never be able to file a MP against cu2d-config ;)
[10:13] <fginther> vila, you're the new maintainer :-)
[10:13] <vila> ha ha ha, brace yourselves !
[10:29] <pete-woods> hi all! can anyone tell me how to configure a PPA to build ARM packages?
[10:30] <vila> fginther: landed, so,  http://s-jenkins.ubuntu-ci:8080/job/deploy-cupstream2distro-config/ with stacks=stacks/no-dailies/mir.cfg  ?
[10:31] <fginther> vila, that's correct
[10:31] <vila> fginther: two questions: should I check that no jobs are running ? do you deploy all jobs on a regular basis ?
[10:31] <fginther> vila no and no
[10:31] <vila> fginther: ack
[10:32] <fginther> vila, the deploy script ensures that jobs are not in progress before deploying them, as a result the deploy script can take some time as it waits for jobs to complete
[10:33]  * vila nods
[10:33]  * vila monitors http://s-jenkins.ubuntu-ci:8080/job/deploy-cupstream2distro-config/183/console
[10:40] <vila> dednick: once the job above completes, you should be all set, ideally we'll have you trigger a run to ensure this works as expected, do you have a failing job to test with ?
[10:43] <vila> dednick, fginther: oh, hmm, many running jobs to wait for, this will take longer than I thought
[10:51] <dednick> vila: failing job: https://jenkins.qa.ubuntu.com/job/unity-mir-devel-ci/10/
[10:52] <dednick> http://s-jenkins.ubuntu-ci:8080/job/unity-mir-devel-ci/10
[10:57] <vila> fginther: hmm, is it enough to add D09add_ppa~mir-team~staging to the 'hooks' parameter in the job above to test the job without waiting for the new config to be deployed ?
[10:57] <vila> fginther: in a re-run that is
[10:57] <vila> *rebuild
[11:18] <sil2100> brb, going for lunch - I'll be around on IRC
[11:32] <ogra_> cyphermox_, so i was asked to revert the lxc-android-config upload today to make sure we csan promote if that gets possible ... are you ok with only having it in image 41 to get the needed debug data ?
[12:19] <vila> dednick, fginther: http://s-jenkins.ubuntu-ci:8080/job/deploy-cupstream2distro-config/183/console just finished, I'll re-run http://s-jenkins.ubuntu-ci:8080/job/unity-mir-devel-ci/10 with the added ppa (I've checked that the job has been properly updated for the next runs)
[12:19] <fginther> vila, make sure you just don't hit the rebuild link
[12:19] <vila> fginther: I did, what's the issue ?
[12:20] <fginther> vila, rebuild will reuse the exact same parameters, you need to make sure the new parameters (with the ppa hook) are added
[12:20] <vila> fginther: oh yes, I did, I *added* the ppa after checking that the next runs will include it
[12:20] <Mirv> sil2100: so.. nik90_ managed to trigger an association in my head - so I've seen locally that sometimes evolution-calendar-service and indicator-datetime start both consuming 100% CPU, possibly after running calendar app AP tests. so the theory nekhelesh is now testing is that clock app AP starts being extra flaky at least someties if it's run after the calendar app AP tests
[12:20] <fginther> vila, ah, then it should be ok
[12:21] <Mirv> sil2100: and this CPU burning is a situation that persists over reboots, unless one wipes the device or removes enough the the .config/.local/.cache contents
[12:22] <vila> fginther: in fact, to avoid tyops, I copied the ppa from the updated job ;)
[12:22] <vila> well, the hook adding the ppa that is
[12:22] <vila> dednick: the job to monitor is http://s-jenkins.ubuntu-ci:8080/job/unity-mir-devel-ci/13/console (and its subjobs)
[12:37] <vila> dednick: http://s-jenkins.ubuntu-ci:8080/job/unity-mir-devel-ci/13/console finished green. Success ?
[12:41] <bregma> where do we file bugs against ci-train itself?
[12:41] <cjwatson> bregma: cupstream2distro project
[12:47] <sil2100_> Mirv: oh
[12:47] <sil2100_> Mirv: that makes some sense, didn't know the CPU burning was so serious (i.e. persisting over reboots)
[12:48] <sil2100_> Mirv: I think this might need a bug and some serious investigation
[12:48] <sil2100_> davmor2: so, as for testing, we might need the 'next' image we produce tested
[13:03] <cyphermox_> ogra_: not really, we still haven't fixed all these bugs
[13:03] <cyphermox_> is it blocking promotion in any way?
[13:03] <ogra_> yes
[13:04] <ogra_> sil2100 doesnt like to promote with extensive loggin
[13:04] <ogra_> you have image 41 to get  the data, thast possibly enough
[13:04] <ogra_> unless you strongly feel it is not indeed :)
[13:04] <sil2100> cyphermox_, ogra_: I would just like to have the next image without debugging, as #41 can be used as the 'data logger'
[13:05] <sil2100> But I'm open to propositions ;)
[13:05] <cyphermox_> meh
[13:05] <cyphermox_> do as you want
[13:06] <ogra_> i dont care either way and can upload a revert or not ... but i dont like an upset cyphermox_ :)
[13:09]  * sil2100 wouldn't like an upset cyphermox_ as well
[13:09] <cyphermox_> if you feel it's necessary to revert, please do
[13:10] <sil2100> Especially that we're counting so much on cyphermox_'s and rsalveti's combined efforts on that WiFi issue ;) And manta ;p
[13:10] <cyphermox_> ogra_: did the new network indicator come up with #28?
[13:10] <ogra_> cyphermox_, yes
[13:10] <ogra_> i guess yourefer to the new bug
[13:10] <ogra_> not sure why he didnt get it running with 28
[13:10] <sil2100> cyphermox_: actually in 28 it got 'fixed', as it landed in 27 but without urfkill
[13:11] <ogra_> oh
[13:11] <ogra_> wait
[13:11] <ogra_> no
[13:11] <ogra_> the new indicator was after 28
[13:11] <sil2100> Right, indeed
[13:11] <ogra_> landed in 30 or so ... but without unity8 so we had it broekn til ... hmm ... i think 31
[13:11]  * ogra_ checks
[13:11] <cyphermox_> ah, 29
[13:11] <sil2100> cyphermox_: 29
[13:11] <cyphermox_> ugh
[13:12] <sil2100> Right, too many indicator-network landings...
[13:12] <ogra_> yeah, 29 but broken
[13:12] <ogra_> 31 had the fix in unity8
[13:12] <cyphermox_> how was 28?
[13:12] <ogra_> 28 was fine
[13:12] <cyphermox_> isn't that the last promoted image?
[13:12] <ogra_> we promoted it
[13:12] <cyphermox_> right
[13:12] <ogra_> running it here quite happily
[13:12] <cyphermox_> so what was the state of manta on 28?
[13:13] <ogra_> we had issues in the lab
[13:13] <cyphermox_> so no tests?
[13:13]  * cyphermox_ sighs
[13:13] <ogra_> iirc you and me talked abouut it and you thought it was a driver issue
[13:13] <sil2100> No tests, manta was anyway in no 'good' state since a long time
[13:13] <ogra_> manta broke in 27 http://ci.ubuntu.com/smokeng/utopic/touch/
[13:14] <ogra_> and had no successful tests since
[13:15] <cyphermox_> ugh
[13:15] <cyphermox_> it's not even half done
[13:15] <cyphermox_> that's worthless
[13:27] <vila> dednick: ping
[13:29] <sil2100> bfiller: how's testing of the content-hub landing going?
[13:29] <bfiller> sil2100: been in meetings all day, about to test it
[13:30] <dednick_> vila: yo. that seems to have done the trick.
[13:30] <sil2100> bfiller: thank you :)
[13:30] <bfiller> sil2100: ken said it was working from the silo but I will verify
[13:31] <ogra_> yeah, we dont trust ken :P
[13:31] <vila> dednick_: ack, good then
[13:50] <nik90_> sil2100: I was able to test and confirm Mirv's theory. So if you run the calendar before the clock app, you then have 5 failures (on image 41) on a clean wiped phone. If you don't run the calendar tests, then there is only 1 clock test failure which is related to the SDK regression that you are already aware of.
[13:51] <sil2100> nik90_: ah! Damn, that would make sense as the order of tests on smoketesting varies between runs
[13:51] <sil2100> nik90_, Mirv: good catch!
[13:51] <sil2100> nik90_, Mirv: I wonder since how long we have that CPU burning bug, we'll have to track that down anyway and fill a bug
[13:51] <nik90_> sil2100: I am reporting the bug against indicator-datetime and EDS since Mirv said both were showing high CPU usage.
[13:52] <nik90_> sil2100: I will check with renato if he has any thoughts on this.
[13:52] <sil2100> nik90_: thanks, awesome :)
[13:52] <nik90_> yw
[13:52] <sil2100> nik90_: btw. do you know what's the status of the SDK regression? Any news on that being handled?
[13:52] <sil2100> Is a fix for that in staging already?
[13:53] <nik90_> sil2100: there is already a fix which has been approved and merged into staging.
[13:53] <nik90_> sil2100: there is currently a SDK landing which is being tested across all apps. They have 4 failures across other apps. Until that clears up, they wont release it
[13:53] <sil2100> Excellent, so it's in the UITK silo then
[13:53] <sil2100> That's great news
[13:54] <nik90_> sil2100: yes
[13:54]  * sil2100 likes such news
[13:54] <sil2100> ;)
[13:54] <nik90_> :)
[13:57] <mhr3> sil2100, reconf 011 pls
[13:58] <sil2100> mhr3: ACK
[13:59] <sil2100> mhr3: done
[14:00] <mhr3> ty
[14:04] <davmor2> sil2100: sure give me  a ping when it's done I'm kinda all over the place
[14:22] <rsalveti> Mirv: ubuntu-ui-toolkit was just uploaded, are you also uploading the -gles version as well?
[14:22] <rsalveti> thought that the -gles package would be part of the same silo
[14:23] <rsalveti> let me update it again
[14:25] <sil2100> popey: who's the main upstream developer of the terminal app?
[14:25] <Mirv> rsalveti: right, for UI Toolkit we should insert this to bzoltan's teams preparations of the PPA. so when it's tested, one more step to upload -gles to the same PPA. but I should have caught it before publishing, I guess this just needs rinse and repeating before it becomes routine.
[14:26] <Mirv> sorry about that, I even have a note of it on top of my todo list that if any of the list of these packages come in, remember gles...
[14:26] <rsalveti> Mirv: yeah, no worries, we'll get used to it :-)
[14:38] <popey> sil2100: there isnt one
[14:40] <barry> mandel: any word on the new udm?
[14:40] <mandel> barry, I'm trying to get a silo with several fixes (I needed to add a mms fix) as soon as it is there I'll ping you
[14:40] <bfiller> sil2100: content-hub silo is going to need another MR (: we're working on it
[14:41] <sil2100> bfiller: ACK! If a reconfigure from us is needed, just give me a poke :)
[14:41] <barry> mandel: sounds good, thanks
[14:44] <popey> sil2100: why, is there a problem?
[14:44] <sil2100> popey: no, just creating a list
[14:46] <mandel> barry, the bug was "quite simple" the canceled signal was raised on error before the error signal was, the reason, we cancel all downloads in a group download when there is an error
[14:46] <barry> mandel: hmm.  i wouldn't expect both an error signal and a cancel signal
[14:47] <mandel> barry, that is the bug, just error should be raised
[14:47] <barry> ah, gotcha
[14:49] <mandel> barry, and that is the reason why none of my scripts was seeing the error, because I was not using a group downloads :-/
[14:52] <barry> mandel: i think it would make a lot of sense to add integration tests both to dep-8/autopkgtest and in the udm test plan
[14:53] <mandel> barry, yes, definetly
[14:53] <mandel> barry, I have always added the system updates happy path to my test plan
[14:53] <mandel> barry, we never tested a 404 for example
[14:54] <barry> mandel: do you test against the real system-image.ubuntu.com?
[14:54] <mandel> barry, yes, I always go back several images, install the silo udm and do an update
[14:55] <barry> mandel: that explains why the 404 path was never tested.  s-i.u.c has a blacklist keyring.  most of the unittests in s-i don't
[14:55] <barry> (and a 404 is an expected use case)
[14:55] <mandel> barry, exactly
[14:59] <barry> mandel: there's also this: https://bugs.launchpad.net/ubuntu/+source/system-image/+bug/1321481
[15:00] <mandel> barry, then we have no excuse not to have them ;)
[15:00] <barry> mandel: exactly.  i will definitely add stuff to s-i's autopkgtest.  should i open a new bug on udm for similar, or just add a bugtask to 1321481
[15:01] <mandel> barry, yes please
[15:01] <barry> mandel: which one? :)
[15:02] <mandel> barry, first, sorry hehe
[15:05] <ogra_> Wellark, did you see my ping from this morning about the crash ?
[15:06] <barry> mandel: LP: #1321795
[15:09] <ted> What's the channel for the ci-train bot?
[15:10] <ogra_> ubuntu-choo-choo or some such
[15:10] <mandel> ted, ubuntu-ci-choo-choo
[15:10] <ogra_> or ci-choo-choo
[15:10] <mandel> ted, don't listen to ogra, listen to me :)
[15:10] <ogra_> right
[15:10] <mandel> ogra_, buuuu
[15:11] <ogra_> :)
[15:11] <mandel> ogra_, I just crashed firefox..
[15:11] <ted> Heh, thanks guys :-)
[15:17] <davmor2> I'm going to do a fresh flash I think, cyphermox_ awe_ If I flash to an older version and upgrade will those logs be of use to you guys?
[15:17] <Wellark> ogra_: sorry, no.
[15:17] <cyphermox_> davmor2: yes
[15:18]  * sil2100 archives landings
[15:18] <cyphermox_> davmor2: though enabling debugging logs is even better after you do the initial flash, before OTA
[15:18] <davmor2> right give me a bit then
 Wellark, how is the work on the .crash going ?
 Wellark, given it shows up on every dialer-app test it should be very easy to reproduce it locally so you can gather the backtrace on your phone
[15:18] <nik90_> Mirv: forgot to link you the bug report, https://bugs.launchpad.net/ubuntu/+source/qtorganizer5-eds/+bug/1321775
[15:18] <davmor2> cyphermox_: right I'll ping you when the flash is done then
[15:18] <cyphermox_> davmor2: I should be able to reproduce the issue, we need to find out exactly how to reproduce it
[15:19] <Mirv> nik90_: great, thanks!
[15:19] <nik90_> Mirv: well thnk you for the theory :)
[15:24] <tedg> Can someone hit build on silo 6 for me? Seems Google docs only works with a pointer for URLs.
[15:24] <tedg> I lost all my pointer devices upgrading to Utopic :-/
[15:26] <ogra_> use a phone, touchscreens work :P
[15:26] <sil2100> Oh
[15:26] <sil2100> tedg: ok, sure
[15:26]  * ogra_ doesnt want to know how the spreadsheet looks on a phone though :)
[15:27] <tedg> ogra_, Interestingly the touch screen on my laptop is working intermittently, but chrome seems to see that as a gesture device and won't allow clicking on the buttons in the spreadsheet with it.
[15:27] <tedg> sil2100, Thanks!
[15:28] <ogra_> yeah, you need to install ubuntu touch then ;)
[15:28]  * ogra_ tries to look innocent
[15:29] <tedg> Oh, I would if Mir would work on my system :-/
[15:29] <tedg> Not sure what's up there. Perhaps try again with the new kernel in Utopic.
[15:29] <Wellark> ogra_: i will take a look ASAP
[15:29] <Wellark> which might be next week, though.. :(
[15:30] <Wellark> as long as we don't have AP tests failing for that
[15:30] <davmor2> cyphermox_: by the way why is bluetooth always on on reboot again?
[15:30] <cyphermox_> should be?
[15:30] <mandel> barry, I forgot to mention, can you take a look at https://code.launchpad.net/~mandel/ubuntu-download-manager/canceled-signal/+merge/220487
[15:30] <davmor2> cyphermox_: no it's on, on every reboot even if you turn it off
[15:31] <barry> mandel: diff updating.  do you want me to try the patch or just review it?
[15:31] <mandel> barry, try the patch and confirm that it works
[15:32] <mandel> barry, the patch is tiny
[15:32] <mandel> barry, fix and update the test to check that the signal is not raised
[15:32] <davmor2> cyphermox_: any way phone rebooted what do you want doing?
[15:32] <sil2100> Oh shit, it's so late already, almost time for the meeting
[15:32] <tedg> Ah, found it in the help. Open a URL with "Alt+Enter"
[15:33] <cyphermox_> davmor2: are you seeing the bug right now?
[15:34] <barry> mandel: taking a while to update the diff.  can you pastebin me a patch?
[15:35] <davmor2> cyphermox_: meh no this time it's come up
[15:35] <davmor2> brb
[15:40] <mandel> barry, http://paste.ubuntu.com/7497869/
[15:40] <mandel> barry, is that good enough?
[15:41] <barry> mandel: that should work.  i'll apply that on top of the exit fix
[15:44] <davmor2> cyphermox_: let me retry
[15:46] <tedg> What's the situation with platform API on arm64, powerpc and ppc64el ?
[15:46] <tedg> Seems like it's changed for Utopic?
[15:47] <tedg> My package is dep-waiting on the library there.
[15:50] <tedg> I guess the real question, can I release the package with those in dep-wait? :-)
[15:55] <davmor2> cyphermox_: \o/ no I have it again
[15:55] <davmor2> but lets talk after the meeting now :)
[15:56] <sil2100> \o/
[15:57] <cjwatson> tedg: Nothing has changed in utopic
[15:57] <cjwatson> tedg: Which package?
[15:58] <tedg> cjwatson, Indicator-location, but it's just waiting. https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+packages
[15:58] <tedg> I assumed they were failing to build or something?
[15:59] <cjwatson> tedg: That's fine, since indicator-location isn't built on those architectures in utopic.  rmadison -s utopic -S indicator-location
[15:59] <cjwatson> tedg: Only architecture support *regressions* are a problem.  This isn't.
[15:59] <tedg> cjwatson, Ah, okay. Cool, thanks.
[16:00] <sil2100> bfiller: how's the testing of the content-hub landing going?
[16:00] <bfiller> sil2100: updating right now,, will konw in a few
[16:01] <davmor2> Mirv: meeting
[16:01] <sil2100> robru: meeting!
[16:02] <lool> sil2100: heya
[16:02] <sil2100> lool: hey!
[16:02] <lool> just a heads up that I've pushed the 14.10-dev1 frameworks
[16:03] <lool> this is exactly like the 14.04 addition that we have in archive and not in image, so it doesn't change anything
[16:03] <lool> (in both cases no app is using the frameworks)
[16:03] <lool> (just wanted to mention it so that it doesn't come as a surprize)
[16:03] <cjwatson> lool: an MP for lp:click/devel to educate click/chroot.py about that would be appreciated
[16:03] <lool> cjwatson: ah right, major versions need to be listed
[16:04] <lool> I remember that -devN dont need a click change, but major versions do
[16:05] <lool> oh I remembered wrong
[16:06] <cjwatson> They shouldn't need a click change but sort of slightly do
[16:06] <cjwatson> You don't actually have to pass the -devN bit to click chroot though ...
[16:07] <cjwatson> click chroot ought to apply some regex heuristics or something
[16:07] <lool> cjwatson: apparently it needs it for the -html and other -foo-devN cases
[16:07] <cjwatson> Only if you pass those on the command line
[16:07] <cjwatson> As I say
[16:08] <cjwatson> You don't actually have to do that
[16:08] <lool> ah I see
[16:08] <lool> well I've listed the others there too for consistency
[16:17] <sil2100> bfiller: oh, btw.!
[16:17] <sil2100> bfiller: we wanted to know, will the content-hub landing also fix the 4 gallery-app failures we're seeing?
[16:18] <sil2100> bfiller: on smoketesting
[16:19] <davmor2> cyphermox_: right what am I doing while I'm on the not so crap network
[16:22] <bfiller> sil2100: no won't fix that, we have another MR for that unrelated
[16:23] <cyphermox_> davmor2: have you reproduced wifi off on boot?
[16:24] <davmor2> cyphermox_: yes I re-flashed it
[16:24] <bfiller> sil2100: ok silo 18 content-hub ready to land :)
[16:25] <cyphermox_> davmor2: great.
[16:26] <cyphermox_> can you get me these?  http://paste.ubuntu.com/7498013/
[16:27] <sil2100> Yess!
[16:27] <sil2100> robru: will you handle silo 18? :)
[16:27] <sil2100> bfiller: thanks for the info, we'll be waiting for that merge to land as well o/
[16:29] <davmor2> cyphermox_: http://paste.ubuntu.com/7498031/
[16:30] <cyphermox_> eh, what?
[16:30] <cyphermox_> why is all of this disabled?
[16:30] <cyphermox_> oh wait
[16:30] <cyphermox_> you rebooted a bunch of times, right? this isn't just a clean flash?
[16:32] <davmor2> cyphermox_: no this is a fresh bootstrap, but I turned off bluetooth and 3g data to stop it roaming wifi is untouched
[16:32] <cyphermox_> but it was rebooted?
[16:32] <cyphermox_> which image is this?
[16:32] <davmor2> cyphermox_: 40 so I can ota to 41
[16:33] <cyphermox_> ah
[16:33] <cyphermox_> run /usr/share/urfkill/scripts/block wifi 0
[16:33] <cyphermox_> then reboot and see if wifi is still broken
[16:33] <cyphermox_> hopefully it will be :'(
[16:34] <davmor2> I might need to move in a minute
[16:35] <davmor2> but I don't want crappy wifi
[16:36] <bfiller> sil2100: silo 17 readyt to release as well
[16:36] <davmor2> cyphermox_: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-05-21-173533.png
[16:36] <cyphermox_> davmor2: ok, I'll just need the same list of commands again
[16:37] <davmor2> cyphermox_: 1 second
[16:38] <davmor2> cyphermox_: http://paste.ubuntu.com/7498069/
[16:39] <cyphermox_> can you run rfkill list again?
[16:40] <davmor2> http://paste.ubuntu.com/7498078/
[16:42] <davmor2> cyphermox_: back in a bit need to get out of here
[16:42] <barry> mandel: Ran 352 tests in 945.460s
[16:42] <cyphermox_> k
[16:42] <barry> mandel: \o/
[16:47] <robru> sil2100, oh sorry, I was eating breakfast. what happened in silo 18?
[16:48] <sil2100> robru: ah, it's ready for publishing :)
[16:48] <mandel> barry, awesome! will get this landed asap
[16:48] <bfiller> robru: silo 18 and 17 ready for publish
[16:48]  * sil2100 forgot it's still early for robru 
[16:48] <sil2100> robru: will you take care of the landings?
[16:48] <Mirv> I did 17
[16:48] <robru> sil2100, yep I'm on it now. I see an error on 18 though
[16:48] <Mirv> bfiller: I think 18 needs watch only run, let me do it
[16:48] <robru> Mirv, ok you do it ;-)
[16:48] <Mirv> no I'm not working from hotel room
[16:48] <bfiller> Mirv: what's the problem with it?
[16:49] <Mirv> bfiller: so it claims address-book-app was not built, while it was
[16:49] <bfiller> Mirv: weird maybe because it was a no-change rebuild?
[16:49] <Mirv> bfiller: when trying to publish. so running watch_only build task first (https://ci-train.ubuntu.com/job/landing-018-1-build/39/console) trying again then
[16:49] <robru> Mirv, I usually see that happen when a silo gets reconfigured and then only one package built after the reconfigure.
[16:49] <Mirv> bfiller: it shouldn't matter AFAIK unless there's some new bug
[16:50] <bfiller> robru: also need a silo for line 31 to fix gallery AP failures
[16:50] <Mirv> robru: hmm didn't help, can you look it further? maybe it needs reconfig _and_ watch only build?
[16:50] <davmor2> cyphermox_: right back with you
[16:51] <Mirv> the package is there in the PPA
[16:51] <robru> Mirv, it probably got itself so confused at this point that it will require a rebuild
[16:52] <robru> bfiller, ok you got silo 20
[16:53] <Mirv> robru: yep doesn't seem to be resolved just like that
[16:53] <Mirv> ok, good luck, me -> again
[16:54] <davmor2> Mirv: if it was that easy we'd all be doing it ;)
[16:55] <davmor2> cyphermox_: any joy?
[17:11] <dobey> why would there be a successful autolanding job for a branch, and then another one 25 minutes after the first one, for the same branch?
[17:13]  * ogra_ noticed that too for one branch ... i didnt dig though since the first run made it land in trunk 
[17:16] <dobey> yeah, it was merged to the branch fine. it's just weird since i have another branch waiting to land. i would expect that branch should have landed by now, since those previous 2 runs were only 25 min apart, and it's been an hour since the last run now (or maybe it's already running and i just can't see it yet because i'm looking at the public page)
[17:16] <dobey> hah. indeed. just refreshed and another job appeared
[17:17] <dobey> but weird
[17:25] <davmor2> cyphermox_: dude I need to go eat, if you think of anything send me a mail and I'll look at it when I get back
[17:25] <davmor2> Mirv: bar ad food call dude
[17:42] <sil2100> robru: hi! Did you try a 'watch only' build?
[17:42] <robru> sil2100, mirv already did, total failure
[17:42] <sil2100> Interesting
[17:42] <sil2100> Let me check the logs again
[17:43] <robru> sil2100, yeah, try to compare the timestamps on the build & publish jobs and you'll quickly see a narrative of what went on
[17:43] <sil2100> robru: ok, looking into that now!
[17:46] <sil2100> hmm, interesting things are going on here
[17:46] <robru> sil2100, yeah, it confused itself somehow, inconsistent state
[17:46] <robru> sil2100, i've seen it before, the way to reproduce it is build all -> reconfigure -> rebuild only one. after the reconfigure it expects everything needs to be rebuilt. I agree WATCH_ONLY is supposed to handle this case, but for whatever reason it fails to work
[17:47] <sil2100> robru: I think I see the problem, let me try thinking of a way to resolve that
[17:47] <sil2100> Give me one moment to understand this
[17:47] <sil2100> ;p
[17:51] <sil2100> Ah...
[17:51] <sil2100> Ok, so I see what happened
[17:51] <sil2100> robru: so, it's something different, and actually the problem is not really on the infra side
[17:52] <robru> sil2100, oh really?
[17:52] <sil2100> robru: so what happened is - theoretically address-book-app didn't even build in the PPA it seems! Did you check if it was in the PPA then? SInce I checked on the backend side and the source package wasn't even built for address-book-app - and the reason for that was:
[17:53] <sil2100> robru: they added a address-book-app 'no-change-rebuild' merge, so an empty merge
[17:53] <sil2100> robru: so, citrain took that merge, applied it, checked that there are no changes and said 'hey, no changes, force rebuild wasn't set so I don't build anything'
[17:53] <sil2100> robru: and basically gave up address-book-app building
[17:53] <sil2100> robru: (since there was nothing new to build)
[17:54] <robru> sil2100, oooohhhhhh
[17:54] <robru> sil2100, I was going to say, look here, bill built it! https://ci-train.ubuntu.com/job/landing-018-1-build/38/console but indeed actually it shows it wasn't built.
[17:54] <sil2100> robru: so what had to be done was flicking the 'force rebuild' flag when address-book-app was added anyway :) Since otherwise citrain will not allow you to release something that didn't have a change
[17:54] <robru> sil2100, no i didn't look at the PPA directly. i thought mirv did, i thought mirv said it was in the ppa already
[17:54] <sil2100> robru: right! I also thought it was, but then I checked the components it was waiting for and was like duh
[17:55] <sil2100> robru: so good that you made a force rebuild :)
[17:55] <sil2100> You actually didn't 'hack fix it' just fixed it properly that way!
[17:55] <robru> sil2100, haha, ok. so false alarm here. but one time in the past I did observe a case where "build -> reconfigure -> build one -> watch_only build" let the silo into an unpublishable state
[17:56] <robru> sil2100, no, wait
[17:57] <robru> sil2100, https://ci-train.ubuntu.com/job/landing-018-1-build/37/consoleFull this one shows bill actually building address book app
[17:57] <robru> sil2100, same revision
[17:57] <sil2100> Oh, force rebuild it said
[17:58] <sil2100> Oh, right
[17:58] <sil2100> robru: so, he did that *before* the reconfigure
[17:58] <sil2100> robru: look at the date, he did that at UTC morning, when the landing was first added
[17:58] <robru> sil2100, yesss... so if the package was already in PPA, why didn't WATCH_ONLY work?
[17:58] <sil2100> robru: when a reconfigure happens, CITrain seems to clean up the state!
[17:59] <sil2100> robru: watch only watches only for the project it sees in the backend
[17:59] <sil2100> robru: since the backend was 'cleaned' with the reconfigure, it stayed in the PPA (as we don't clean the PPA) and there was this strange situation that happened, hah!
[17:59] <sil2100> Now this is something that we need to note down in the FAQ I'm slowly composing ;)
[18:00] <sil2100> *projects
[18:00] <sil2100> Damn
[18:00] <robru> sil2100, yeah, well I think there should be a way to say "ok, I reconfigured, but only one package needs to be rebuilt, not all of them". forcing rebuild of everything after a reconfig is broken, i think
[18:01] <sil2100> robru: right, that might be a good idea, let's think about that during Malta ;) Since this is such a rare case that we need to think if it makes sense to implement with CI Airlines slowly coming our way
[18:01] <sil2100> heh
[18:01] <sil2100> Anyway, I guess it should be ok now
[18:02] <robru> sil2100, yeah, force rebuild now will break out of the trap. but it's a pointless waste of time to have to do that. ;-)
[18:03] <sil2100> ;)
[19:02] <cyphermox_> davmor2: could you test this fix on your mako? https://launchpad.net/~mathieu-tl/+archive/nv-build/+sourcepub/4189611/+listing-archive-extra
[19:02] <cyphermox_> rsalveti mentions it seems to properly fix the issue on manta
[19:18] <Wellark> umm.. why are we not promoting? I don't quite understan what is blocking us
[19:19] <robru> cyphermox_, ogra, rsalveti: whoever's around, silo 18 landed, please kick an image build.
[19:20] <rsalveti> Wellark: network issue
[19:20] <Wellark> all the issues listed are noted to not affect the user experience
[19:20] <rsalveti> it seems cyphermox_ just got a fix for it
[19:20] <rsalveti> manta is dead currently
[19:20] <Wellark> network issues does not affect the user experience either
[19:21] <Wellark> as it's just a simple switch from the indicator
[19:21] <rsalveti> well, but it is a regression
[19:21] <rsalveti> and we should fix it
[19:21] <rsalveti> enabling again our manta devices in the lab is a big thing
[19:21] <Wellark> and this is worth declaring TRAINCON-0 ?
[19:21] <rsalveti> well, that's not my call
[19:21] <Wellark> just trying to understand..
[19:22] <rsalveti> robru: will kick it
[19:22] <rsalveti> done
[19:22] <robru> rsalveti, thanks
[19:23] <rsalveti> cyphermox_: will you push your nm fix as well?
[19:23] <rsalveti> we should try to get it in and kick another image later today
[19:24] <robru> oh damnit, i forgot to check rmadison again. rsalveti can you cancel the image build?
[19:24] <robru> stupid launchpad stupid lying to me...
[19:26] <cyphermox_> rsalveti: I as waiting to get news from davmor2
[19:26] <rsalveti> robru: I can't
[19:26] <cyphermox_> if you think I should just ship it, I'm fine with that too, as it provably fixes manta
[19:27] <rsalveti> cyphermox_: yeah, just push it
[19:27] <robru> rsalveti, bah
[19:27] <cyphermox_> fair enough
[19:27] <rsalveti> cyphermox_: don't think davmor2 will be back today still
[19:27] <rsalveti> then he can just validate the new image
[19:30] <imgbot> [19:32] <cyphermox_> uploaded.
[19:33] <cyphermox> bet autopkgtests won't pass ...
[19:35] <cyphermox> maybe they will after all
[20:40] <davmor2> rsalveti, cyphermox: I'll have a look for you
[20:50] <imgbot> [20:50] <imgbot> [20:50] <Mirv> robru: sil2100: so the address-book-app was there in the PPA already, interestingly
[20:50] <Mirv> (ok, reading further, so you found out too)
[20:51] <robru> Mirv, yeah, I noticed that because if you look at bill's second-to-last build job (#37 i think?) it shows him force-building it and it shows teh upload to teh ppa happening
[20:51] <Mirv> pretty strange anyhow, a good read in the backlog :)
[20:51] <davmor2> cyphermox: I see networks \o/
[20:52] <rsalveti> davmor2: great!
[20:52] <rsalveti> cyphermox: then it was indeed the same issue
[20:52] <rsalveti> next image should have the fix
[20:53] <davmor2> rsalveti: can you have a quick look at something else I just noticed,  try disconnecting from a network
[20:54] <davmor2> rsalveti: and the bad news now is I don't seem to be able to connect let me check i didn't miss a package
[20:56] <sil2100> Mirv: ;)
[20:56] <rsalveti> davmor2: works fine here, but that might be an indicator issue
[20:57]  * sil2100 EODs now, about time
[20:57] <sil2100> o/
[20:57] <tedg> Okay, so tested those silos.
[20:57] <tedg> Now do I push "Publish" or is that someone else?
[20:58] <tedg> cyphermox, robru ? ^
[20:58] <davmor2> rsalveti: let me nip down to the conference center floor it might be that it is just not connecting to the crappy hotel network back in five
[20:58] <tedg> Oh, apparently not me.
[20:59] <tedg> The train is moving!
[20:59] <Mirv> choo choo
[20:59] <Mirv> good night
[21:02] <davmor2> rsalveti: connected to the canonical network no issues so it was just the hotel wifi \o/
[21:02] <rsalveti> davmor2: great
[21:03] <davmor2> night Mirv
[21:04] <davmor2> rsalveti: so you dropping that fix in the next image right? should it work on manta too do you want me to try it there aswell?
[21:04] <rsalveti> davmor2: already tested on manta, so it should be good on all devices
[21:04] <rsalveti> davmor2: and yeah, will be part of the next image
[21:09] <cyphermox> yeah... it's late for regrets ;)
[21:12] <davmor2> cyphermox: rsalveti: \o/ works on manta too \o/ nice one guys :)
[21:14] <rsalveti> davmor2: yeah :-)
[21:15] <davmor2> so I'll do a fresh install of 42 tonight upgrade in the morning and make sure it works on a real image and with all luck that will be an image with no blockers \o/
[21:15] <rsalveti> yeah, so we hope :-)
[21:18] <robru> tedg, I published already
[21:18] <robru> tedg, in fact they're both already through proposed already, you can merge & clean both silos now. thanks
[21:29] <tedg> Cool
[21:29] <tedg> robru, Thanks!
[21:30] <robru> tedg, you're welcome!
[22:14] <cjwatson> robru: the livefs-on-LP work will give us cancellable image builds, at least in theory :)
[22:14] <cjwatson> (well, technically it's possible for IS to kill a build, but with the amount of faff involved it's very rarely worth it)
[22:14] <robru> cjwatson, good to know, thanks
[22:18] <cjwatson> maybe we ought to hook up the corresponding LP API calls to iso.qa.ubuntu.com so that it can proxy the relevant privileges
[22:18] <cjwatson> or maybe I should have the notion of a build requested on behalf of somebody else, so that you can cancel directly from your browser ... will have to ponder that
[22:43] <ogra_> cyphermox, can you do the lxc-android-config revert too ? seems we have enough time til the proper image builds anyway :)
[22:43] <cyphermox> ogra_: revert of? debug?
[22:44] <ogra_> yeah, i didnt do that yet since it didnt look like we would have something promotable anyway
[22:44] <cyphermox> sure, in a second
[22:44] <ogra_> merci :)
[22:52] <robru> cjwatson, cancelling builds from the browser would be nice, but it would be even nicer if launchpad didn't lie to me about whether or not a package was really in the release pocket or not