[02:04] <imgbot> [03:39] <imgbot> [03:40] <imgbot> [07:14] <sil2100> o/
[07:14] <sil2100> This heat is killing me...
[07:38] <popey> hello! this is new! http://popey.mooo.com/screenshots/device-2014-07-18-083826.png
[07:41] <sil2100> Ooooh
[07:41] <sil2100> Since when do we have that?!
[07:41] <popey> dunno, only just noticed it
[07:42] <popey> in proposed
[07:42]  * sil2100 checks commitlogs
[07:45] <Mirv> that's awesome, I've been waiting for that too :)
[07:46] <sil2100> Mirv: o/
[07:46] <sil2100> Mirv: I thought you're on holidays already :)
[07:46] <sil2100> ogra_: hmmm... I wonder why the changes file for 137 is empty - I guess it was the Mir image, right?
[07:47] <jibel> sil2100, popey the shutdown prompt comes from unity8 7.90+14.10.20140717.1-0ubuntu1
[07:48] <popey> sil2100: the file was 403 initially, and 0 bytes long, guessing ogra's script failed
[07:49] <sil2100> jibel: oh, thanks ;)
[08:02] <Mirv> sil2100: after today :) just gave you a prenotice
[08:32] <tvoss> sil2100, Mirv something wacky in the ci infrastructure: https://ci-train.ubuntu.com/job/landing-008-1-build/
[08:39] <brendand> popey, https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1342336
[08:39] <robru> tvoss, nope, it's your stuff that's broken: https://code.launchpad.net/~vorlon/process-cpp/explicit-gcc-version/+merge/226564
[08:39] <robru> actual 404 ;-)
[08:41] <cjwatson> looks like a typo, should be https://code.launchpad.net/~vorlon/process-cpp/explicit-gcc-version/+merge/226594
[08:41] <cjwatson> (there was a previous version of the MP but that was 226569)
[08:42] <robru> mysterious
[08:42] <robru> tvoss, anyway ^ update that link & reconfigure, should work
[08:53] <alan_g> cihelp: I've a problem with mir-mediumtests-utopic-touch and mir-mediumtests-runner-mako which amounts to "dpkg ... --auto-deconfigure will help" - how do I get the scripts updated? (For an example see: https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/2109/console)
[09:00] <sil2100> tvoss: looking
[09:00] <sil2100> Ah, robru already took a look
[09:00] <tvoss> sil2100, already fixed, thanks
[09:00] <tvoss> sil2100, or better: understood
[09:00] <sil2100> robru: shouldn't you be like, sleeping? ;)
[09:00] <brendand> sil2100, https://bugs.launchpad.net/autopilot/+bug/1328600
[09:00] <robru> sil2100, what? it's only 2AM here...
[09:05] <brendand> sil2100, i'll look at the uitk issue and try and see if anything is wrong there. obviously there is an issue with autopilot too, but it doesn't explain why it started failing all of a sudden
[09:42] <sil2100> brendand: ok, thanks - yeah, I wouldn't suppose that so many should start failing because just of that AP problem
[09:42] <sil2100> brendand: but as we already inspected the changes, we didn't see anything landing that could have caused it
[09:42] <sil2100> But maybe we missed something
[09:44] <cjwatson> plars: the test channel next week will be "ubuntu-touch/stable-staging-proposed"
[09:54] <brendand> sil2100, i found the calendar_app failures are reproducible
[09:55] <brendand> sil2100, i filed a bug for them: https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1343916
[09:56] <popey> thanks brendand
[09:56] <sil2100> Oh
[09:56] <sil2100> brendand: thanks!
[09:57] <camako> sil2100, re-requesting a silo for row 13... Switched "Ready" row to "yes" but not sure if you guys received notification.
[09:58] <sil2100> camako: hi! We might have missed that, let me assign a silo for you
[09:58] <camako> sil2100, thanks!
[09:58] <brendand> sil2100, we could potentially work around the uitk failures in the tests. i'll talk to elopio about it when he's in
[09:59] <sil2100> camako: silo 10 for you! yw
[09:59] <sil2100> brendand: oh, work around? You mean, around the timestamp bug in AP?
[09:59] <camako> sil2100 :-) thanks
[10:00] <brendand> sil2100, yes
[10:00] <t1mp> sil2100: do you have a bug id for the timestamp bug?
[10:01] <brendand> t1mp, https://bugs.launchpad.net/autopilot/+bug/1328600
[10:01] <sil2100> t1mp: ^
[10:02] <sil2100> t1mp: it's an autopilot bug it seems
[10:02] <t1mp> brendand, sil2100 thanks
[10:02] <t1mp> I have seen that bug for all UITK MRs yesterday
[10:03] <asac> fginther: ping me when on, s we can chat about dashboard
[10:03] <alan_g> cihelp: I've a problem with the jobs mir-mediumtests-utopic-touch and mir-mediumtests-runner-mako - how do I get the jobs updated?
[10:03] <alan_g> Currently they use setup_branch: lp:~josharenson/+junk/mir-medium-test-runner-for-jenkins
[10:03] <alan_g> What I want is for them to use : lp:~mir-team/+junk/mir-medium-test-runner-for-jenkins
[10:03] <alan_g> (The latter adds a missing option to dpkg)
[10:03] <bzoltan> sil2100: I do not know who to escalate, but no MR was able to land on the staging branch of the UITK because of this bug : https://bugs.launchpad.net/ubuntu-app-launch/+bug/1329141
[10:04] <sil2100> bzoltan: hi! Yeah, I was also thinking about this one, we discussed it yesterday during the evening meeting
[10:04] <t1mp> bzoltan: so we have two blockers now, this is the other https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1328600
[10:04] <sil2100> bzoltan: someone pointed out that it could be qtubuntu at one point, right?
[10:04] <bzoltan> sil2100:  should I start pushing to the staging branch directly and land it?
[10:05] <bzoltan> t1mp:  large timestamp? Like year and month in it? Wow... that is large
[10:05] <t1mp> sil2100: yes mirv hinted that it might be qtubuntu - https://bugs.launchpad.net/ubuntu-app-launch/+bug/1329141/comments/5
[10:05] <sil2100> bzoltan: hm, you could do that, although I guess this would basically mean you'll have to test more before landing...
[10:05] <sil2100> ricmm: hi!
[10:05] <sil2100> ricmm: could you maybe take a look at the above bug? ^
[10:05] <bzoltan> sil2100:  I do the full test suite anyway
[10:06] <sil2100> ricmm: we're not sure where the actual problem comes from, but some clues point into the direction of qtubuntu
[10:06] <t1mp> bzoltan: for example the timestamp bug can be seen here https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/2383/?
[10:06] <t1mp> bzoltan: that result I got for *all* MRs yesterday
[10:06] <bzoltan> t1mp:  geez
[10:07] <Saviq> cihelp hey guys, this job seems stuck in "recording test results" http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-utopic/479/console
[10:07] <Saviq> cihelp and this VM does not start http://s-jenkins.ubuntu-ci:8080/computer/ps-utopic-server-amd64-3/?
[10:08] <t1mp> bzoltan: indeed
[10:09] <Saviq> cihelp, also, I'd need ssh access to one of the utopic&&amd64 VMs please, gotta debug non-reproducible test failures
[10:12] <psivaa> alan_g: Saviq: i'll take a look at your questions one by one
[10:12] <bzoltan> sil2100:  For us these bugs are showstoppers and have the highest possible severity I have seen so far in the UITK project. I can hack around them by creating a shadow staging branch where I merge all the MR branches and propose that branch for landing and then sync back to the staging ... but that would kill the whole point of the continuous integration and automatic testing.
[10:12] <Saviq> psivaa, thanks
[10:13] <bzoltan> sil2100:  we could not autoland on our staging for 72 hours ... from the point of the UITK there we are running in the 72snd hour of a Jenkins outage
[10:13] <sil2100> Crap :|
[10:14] <sil2100> bzoltan: the biggest problem with this qmlscene crash blocker is that we don't know where to escalate it exactly
[10:14] <sil2100> bzoltan: my first guess is ricmm, but not sure if that's the right path
[10:15] <bzoltan> sil2100: the problem sound like a qtubuntu bug.
[10:16] <sil2100> ricmm: could you take a look at it as soon as possible? (just hope you're around)
[10:16] <bzoltan> sil2100:  the real problem is that I do not think we can expect the autopilot tests of the apps and the uitk to be reliable on the device.
[10:16] <sil2100> bzoltan: with the current results, yes?
[10:16] <bzoltan> sil2100:  not even talking about that a crashing qmlscene will be fatal for the users too
[10:16] <sil2100> bzoltan: yeah, that's why those 2 issues are currently our blocker
[10:17] <sil2100> *blockers
[10:19] <sil2100> bzoltan: I'll also try making sure the right people are working on it
[10:19] <bzoltan> sil2100:  Thank you
[10:20] <sil2100> ogra_: is ricmm working today?
[10:20] <ogra_> sil2100, i think he is in the US, but i wouldnt see why not
[10:20] <sil2100> (i.e. did he take a holiday?)
[10:20] <sil2100> Ah, that would explain it
[10:27] <psivaa> alan_g: do you want to replace the setup branch for ever? (from lp:~josharenson/+junk/mir-medium-test-runner-for-jenkins to lp:~mir-team/+junk/mir-medium-test-runner-for-jenkins)
[10:27] <alan_g> psivaa: that would be great
[10:31] <psivaa> alan_g: ok, i've done that and triggered a rebuild on the failed one
[10:31] <alan_g> psivaa: thanks!
[10:37] <cjwatson> sil2100: How's the citrain generalisation for ubuntu-rtm looking?
[10:42] <sil2100> cjwatson: didn't work on it yet today, let me finish that up later today once I'm done with the issue dashboard for landing purposes, as I'm almost done
[10:44] <cjwatson> sil2100: Right, thanks.  I'm nearing the end of other work items I can do before we actually create it ...
[10:45] <psivaa> Saviq: i can't find the host where 'ps-utopic-server-amd64-3 is supposed to run on.. sorry
[10:46] <Saviq> psivaa, ok, will have to wait for fginther
[10:46] <psivaa> Saviq: ack
[10:55]  * sil2100 goes to prepare lunch
[11:29] <fginther> psivaa, 'ps-utopic-server-amd64-3' is hosted on naartjie. It's failing to revert from its snapshot (seen in jenkins slave log) so its disk image is likely corrupt.
[11:30] <fginther> psivaa, I'll see if we have a usable backup for the image.
[11:30] <psivaa> fginther: ack, thanks. i missed naartjie when cheking
[11:31] <popey> balloons: can you help with updating tests for https://code.launchpad.net/~pkunal-parmar/ubuntu-calendar-app/NewEvent-Contact/+merge/223570 ? - it needs an updated test for adding contacts.
[13:09] <ricmm> sil2100: im here now
[13:09] <sil2100> ricmm: \o/
[13:10] <sil2100> ricmm: did you see that bug already? https://bugs.launchpad.net/ubuntu-app-launch/+bug/1329141
[13:10] <sil2100> It seems to be a blocker for any UITK development
[13:10] <ricmm> what does that mean anyways
[13:10] <ricmm> does it make some specific branches fail?
[13:10] <ricmm> if so, which ones
[13:17] <t1mp> ricmm: let me see
[13:18] <sil2100> ricmm: I think all branches fail from what bzoltan mentioned
[13:19] <t1mp> there is another bug now that also makes the branches fail, so with the current MR we see the other bug
[13:20] <t1mp> this is the other bug that blocks us now - https://bugs.launchpad.net/autopilot/+bug/1328600
[13:20] <t1mp> but before that we didn't have autolanding for a few days because of the qmlscene crashes
[13:20] <t1mp> I'm not sure though if the qmlscene crash affected 100% of the MRs, but a lot (maybe 80%)
[13:20] <t1mp> even changes where we only updated the docs
[13:21] <t1mp> ricmm, sil2100 I think this is one where qmlscene crashed https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/2109/?
[13:21] <t1mp> from this MR https://code.launchpad.net/~nik90/ubuntu-ui-toolkit/improve-header-api-docs/+merge/226113
[13:22] <sil2100> We also saw the qmlscene crashes in smoketesting
[13:22] <t1mp> it failed CI twice, and then autolanding, and then it passed autolanding after an empty commit.
[13:24] <t1mp> this MR also has qmlscene crashes https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/noArchErrors/+merge/225667
[13:25] <t1mp> we are pushing stuff to our staging manually today, that's why some newer MRs are now "Merged". But of course that is not the ideal way of working
[13:28] <t1mp> 15:10:42 < ricmm> does it make some specific branches fail?
[13:28] <t1mp> ricmm: if I would have to guess, I'd say about 80% of CI and autolanding runs failed (for all MRs, independent from what's changed)
[13:29] <ricmm> ok
[13:29] <ricmm> can you get me a reproducible case
[13:33] <t1mp> elopio: have you been able to reproduce the crash locally?
[13:34] <t1mp> bzoltan: ^?
[14:06] <Mirv> tsdgeos: Saviq: sil2100: one more update, check https://wiki.ubuntu.com/Touch/QtTesting (-> qt5-beta2) if you need to test Qt 5.3.1 (even though it's not going in before RTM) for some bug or such. I just now very quickly rushed it together to the extent that I've it running on my mako.
[14:06] <Mirv> + desktop (Qt Creator works too)
[14:07] <Mirv> qtbase+qtxmlpatterns+qtdeclarative+qtwebkit is about "well done", everything else is ad-hoc rush packaging at the moment - but it works :D
[14:07] <Mirv> bzoltan: ^ managed to get Qt Creator running with 5.3.1 too if you want to test something so that you know if there'd be a potential fix to cherry-pick to our 5.3.0 for SDK purposes
[14:13] <cjwatson> bfiller: Hi, do you think https://code.launchpad.net/~cjwatson/gallery-app/static-exiv2/+merge/227275 could be added to silo 1, if you're OK with it?
[14:14] <bfiller> cjwatson: sure
[14:14] <bfiller> cjwatson: I'll add it and rebuild the silo
[14:15] <cjwatson> bfiller: Brilliant, thanks - the plan would then be to upload the click package to the store and get it onto images, drop libexiv2-12 from ubuntu-touch-meta, and then once calligra manages to build (currently blocked on a librevenge MIR) the whole transition should manage to land and silo 1 can be cleaned after that
[14:16] <cjwatson> (The .deb will still depend on libexiv2-*, so it'll still be part of that transition, but we should actually be able to land it all then)
[14:43] <bfiller> cjwatson: getting this error when trying to build silo 1 with gallery: https://ci-train.ubuntu.com/job/landing-001-1-build/122/console
[14:44] <bfiller> cjwatson: I checked force rebuild but still getting error
[14:56] <t1mp> elopio: hello
[14:56] <t1mp> elopio: can you read back here to where I highlighted you? I wonder whether you reproduced https://bugs.launchpad.net/ubuntu-app-launch/+bug/1329141 locally
[14:57] <t1mp> ricmm started to have a look at the bug
[14:57] <ogra_> poor bug
[14:57] <ogra_> :)
[14:59] <cjwatson> bfiller: The one you linked didn't have force-rebuild set; the build immediately after that has force-rebuild set and appears to be working
[14:59] <cjwatson> bfiller: https://ci-train.ubuntu.com/job/landing-001-1-build/123/console
[14:59] <bfiller> cjwatson: ah ok, thanks
[15:00] <elopio> t1mp: ricmm: I've seen the crash in my machine and my phone. But not with simple steps to reproduce, just by running the big toolkit suite or the unity8 applicacion life cycle suite multiple times.
[15:00] <elopio> I'll see if I can get a loop that launches qmlscene with a simple qml until it crashes to see how often it is.
[15:02] <sil2100> Damn...
[15:18] <bzoltan> Mirv:  cool. I will test it on Monday
[15:59] <sil2100> ricmm, t1mp: were you able to get to something?
[16:03] <plars> sil2100: I just killed my browser, be there as soon as I can
[16:10] <kgunn> is there a prob on manta with image # 138 ?
[16:11] <ogra_> could be
[16:11]  * ogra_ doubts mantas actually get mooted more than once per month by regular devs
[16:11] <kgunn> ogra_: i got endless google
[16:11] <ogra_> *booted
[16:12] <kgunn> ogra_: we've been diligent trying to test qtcomp on it
[16:12] <ogra_> (mine has a constantly dead battery )
[16:12] <kgunn> its consistently gotten worse in the virgin image lately
[16:12] <ogra_> (requiring me to charge it at least for 1h first)
[16:12] <ogra_> kgunn, http://ci.ubuntu.com/smokeng/utopic/touch/ surely agrees with you
[16:13] <kgunn> ogra_: was just checking on that ;)
[16:13] <ogra_> 137 and 138 definitely had probs
[16:13] <ogra_> though these devices get not properly charged (only via USB port) which is extra deadly for the manta
[16:13] <ogra_> i.e. the lab devices can be unreliable
[16:23] <cjwatson> bfiller: How does silo 1 look re testing?
[16:24] <cjwatson> Hoping somebody has time to look ...
[16:25] <bfiller> cjwatson: haven't had time to test yet, but plan to do so later this afternoon
[16:26] <cjwatson> ok, cool, thanks
[16:36] <robru> kenvandine, need the merge URLs in column F
[16:39] <kenvandine> robru, how's that look?
[16:40] <robru> kenvandine, looks like system-settings conflicts with silos 4 and 6... you're going to have to coordinate with mterry and kgunn about that
[16:40] <mterry> kenvandine, hello!
[16:41] <mterry> kenvandine, if you want to land quickly, go ahead, don't worry about silo 4
[16:41] <kgunn> kenvandine: just let us know when you land we can rebuild 6
[16:41] <robru> well that was easy ;-)
[16:42] <robru> kenvandine, ok you got silo 18
[16:42] <robru> kenvandine, people.canonical.com/~platform/citrain_dashboard/#?q=kenvandine has the silo status and quick links to the jenkins build jobs
[16:43] <kenvandine> thx everyone :)
[16:43] <robru> kenvandine, you're welcome!
[16:44] <barry> robru: i'll assign myself a silo for row 31
[16:44] <robru> barry, ok ;-)
[16:45] <barry> robru: using my vast experience as a button pushing monkey sheriff
[16:45] <robru> barry, http://bit.ly/1lcoYV3
[16:46] <barry> robru: priceless! :)
[16:46] <barry> robru: anyway, i'm off to lunch.  will check on it later
[16:47] <robru> barry, bon appetit!
[16:47] <kenvandine> robru, do i need to enter any info to start the build?
[16:48] <robru> kenvandine, oh yeah, you need to click the 'build' link at that dashboard URL I gave you, and then that loads the jenkins job, which you have to click 'Build' to make it go. but you have to click it twice, because the first time will just log you in and won't trigger the build
[16:48] <kenvandine> ah
[16:49] <kenvandine> there we go :)
[17:36] <pmcgowan> kenvandine, jonas' merge failed again on the about page tests, something about dbus failing to connect
[17:37] <kenvandine> sigh
[17:37] <robru> fginther, is jenkins having some networking issues? at least one silo can't seem to upload to the PPAs. https://ci-train.ubuntu.com/job/landing-017-1-build/103/console and https://ci-train.ubuntu.com/job/landing-017-1-build/102/console different tracebacks, but both related to dput failing connect to launchpad to upload.
[17:38] <pmcgowan> kenvandine, they passed last time
[17:38] <pmcgowan> he fixed something for the background page should have nothing to do with it
[17:40]  * kenvandine looks
[17:42] <kenvandine> pmcgowan, interesting.. that's the same failure i was seeing running them on my device the other day
[17:42] <kenvandine> but they didn't fail in CI
[17:44] <kenvandine> to rule out flaky tests, i just triggered a rebuild
[17:45] <pmcgowan> kenvandine, seems odd, all accesses to the system dbus
[17:47] <robru> fginther, nm, seems transient, retrying the build fixed it
[17:48] <elopio> ricmm: I've commented the qmlscene bug with a script that will get you a crash.
[17:50] <elopio> robru: once the spreadsheet says my silo is ready to build packages, how do I jump to the next state?
[17:51] <robru> elopio, visit http://people.canonical.com/~platform/citrain_dashboard/#?q=elopio and click 'Build', which opens the jenkins job, then on that page click 'Build' twice (once to log in, once to actually trigger it)
[17:52] <elopio> robru: got it. Thanks.
[18:01] <fginther> robru, good, I could find anything not working from what I could check
[18:01] <fginther> s/could/couldn't/
[18:08] <robru> fginther, hehe, thanks for checking
[18:25] <pmcgowan> kenvandine, you need help testing the silo?
[18:26] <kenvandine> pmcgowan, yes please
[18:27] <kenvandine> i tested call waiting and trying to test the wifi ids change now
[18:27] <kenvandine> but i'm not seeing it
[18:29] <pmcgowan> whats the wifi id change kenvandine?
[18:29] <kenvandine> including extra info in whoopsie reports
[18:29] <kenvandine> i see it now that i read the full MP
[18:29] <pmcgowan> oh
[18:29] <kenvandine> some text changed
[18:29] <kenvandine> but i can't check it
[18:38] <pmcgowan> kenvandine, is it the location info checkbox?
[18:38] <kenvandine> yes
[18:38] <pmcgowan> hmm I cant check it
[18:39] <kenvandine> me either
[18:39] <pmcgowan> seems its not enabled
[18:39] <kenvandine> i get the haptic feedback
[18:39] <kenvandine> so must be enabled
[18:44] <pmcgowan> kenvandine, I dont understand the code there
[18:45] <kenvandine> i'm also not getting sound playback in the sound panel
[18:46] <kenvandine> which i'd assume might be the revert apparmor policy branch
[18:46] <kenvandine> language one looks good
[18:47] <pmcgowan> sigh
[18:48] <pmcgowan> kenvandine, the change to initialize the ringtone so it doesnt scroll works
[18:48] <pmcgowan> but the revert did not
[18:49] <kenvandine> i assume
[18:49] <kenvandine> since i hear no playback
[18:49] <pmcgowan> kenvandine, that change seems to not install the bad profile, but I dont think it deletes it if its there?
[18:50] <kenvandine> although i'm not familiar with the problem that hack was trying to fix
[18:50] <kenvandine> oh... maybe that's the problem
[18:50] <kenvandine> but that'll be a real problem anyway
[18:50] <pmcgowan> right
[18:50] <pmcgowan> so a reflash will work, but not an update
[18:53] <kenvandine> pmcgowan, maybe we should drop some of these branches from the silo and give it another go?
[18:53] <kenvandine> robru, is that what "reconfigure" lets me do?
[18:53] <robru> kenvandine, yep, just update the spreadsheet first
[18:54] <pmcgowan> kenvandine, yes drop those two
[18:54] <pmcgowan> the others seem ok to me
[18:54] <kenvandine> robru, do i update it on the landing-018 tab?
[18:54] <kenvandine> i guess not
[18:54] <robru> kenvandine, nope, on the Pending tab. the silo tab is just a readout basically
[18:54] <robru> except when it isn't, sigh
[18:56] <pmcgowan> kenvandine, so that revert
[18:56] <kenvandine> robru, so it reads the branches out of the spreadsheet?
[18:56] <pmcgowan> kenvandine, I wonder if it works with an image update?
[18:57] <robru> kenvandine, yeah, the jenkins reconfigure job will access the spreadsheet to determine what branches go in the silo.
[18:57] <kenvandine> pmcgowan, not sure, lets ask the experts on monday
[18:57] <robru> kenvandine, in CI Train we're really heavily abusing the spreadsheet, pretending it's a db.
[18:57] <pmcgowan> kenvandine, I am wondering if we should leave it in
[18:57] <kenvandine> i just want to get some of this pile of branches landed
[18:57] <kenvandine> pmcgowan, but how can we test that?
[18:58] <pmcgowan> kenvandine, we cant I think
[18:58] <pmcgowan> kenvandine, if we get an image update we will know
[18:58] <pmcgowan> I bet it works, as would a reflash
[18:58] <pmcgowan> jdstrand, about?
[18:59] <pmcgowan> kenvandine, worst case it does nothing and we need a second fix
[19:00] <kenvandine> well i'm wondering if that sound playback works without that revert
[19:00] <pmcgowan> no it doesnt
[19:00] <kenvandine> oh
[19:00] <robru> bfiller, can you approve the merges in silo 11?
[19:00] <pmcgowan> and I manually fixed it yesterday and heard it work
[19:00] <kenvandine> bugger... now i've removed that branch :)
[19:00] <pmcgowan> with a comand jdstrand gave me
[19:01] <kenvandine> ah, i forgot to build though
[19:01] <jdstrand> pmcgowan: ?
[19:01]  * kenvandine adds again
[19:01] <pmcgowan> jdstrand, the revert in https://code.launchpad.net/~laney/ubuntu-system-settings/revert-apparmor/+merge/227225
[19:01] <bfiller> robru: checking, must have missed some
[19:01] <pmcgowan> will that apply on a system update? as it does not on package install
[19:01] <pmcgowan> seems it stops doing something at install, but does not fix the issue with apt update
[19:01] <jdstrand> pmcgowan: what do you mean it doesn't apply?
[19:02] <jdstrand> oh, you mean the file is not removed
[19:02] <pmcgowan> jdstrand, will a system update remove the offending policy
[19:02] <pmcgowan> right
[19:02] <jdstrand> honestly, I'm not sure
[19:02] <jdstrand> cause I don't know how the image is put together
[19:02] <pmcgowan> it must I think
[19:03] <bfiller> robru: done
[19:03] <jdstrand> /etc/apparmor.d is ro
[19:03] <robru> bfiller, published!
[19:03] <pmcgowan> jdstrand, so is everything that gets updated
[19:04] <pmcgowan> I vote we leave that branch in
[19:04] <pmcgowan> kenvandine, ^^
[19:04] <jdstrand> I know, was was saying that is a good thing. so if the stuff that puts the image together is built from debs
[19:04] <jdstrand> and the debs don't contain it
[19:04] <pmcgowan> exactly
[19:04] <jdstrand> then it shouldn't be there
[19:04] <kenvandine> pmcgowan, ok, reconfiguring again
[19:05] <pmcgowan> I commented on the diagnostics mp
[19:05] <kenvandine> pmcgowan, thx
[19:05] <pmcgowan> I gotta eod early, talk to you later
[19:05] <kenvandine> have a great weekend!
[19:05] <pmcgowan> you too
[19:14] <barry> robru: my build failed ^^ which isn't totally unexpected, but i'm missing a button (or don't remember how) to retry the build
[19:15] <robru> barry, ok, depends -- do you have new commits to upload, or is it a transient failure you want a no-change retry?
[19:15] <barry> robru: the latter
[19:15] <barry> (sometimes udm dbus just times out for reasons we've never been able to track down)
[19:15] <robru> barry, ok, then you need to click through to the PPA, and find the ppa build job and click retry there (citrain isn't even involved in that)
[19:16] <robru> well, once you do that, do a WATCH_ONLY citrain build job so that citrain notices when the new rebuild completes
[19:16] <barry> yeah, there's no retry button.  must be some other permission issue going on
[19:16] <robru> barry, you're looking here? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-020/+build/6195265
[19:16] <robru> I see the retry button, not sure why you don't
[19:18] <barry> robru: yeah, me neither
[19:18] <robru> barry, ok, retried it for you
[19:18] <barry> what team are you in that i'm not in? :/
[19:18] <barry> thanks
[19:18] <robru> barry, probably ppa service team
[19:18] <robru> barry, https://launchpad.net/~ci-train-ppa-service
[19:19] <robru> pester asac for access to that
[19:19] <barry> could be.
[19:19] <barry> yeah, will do
[19:20] <barry> or slangasek since he's also an admin
[19:20] <robru> barry, anyway, now run the jenkins build job, but check WATCH_ONLY, and then you'll get nice things like a queuebot ping when the new rebuild is done
[19:23] <robru> alright, I gotta run for lunch, brb!
[19:29] <charles> ogra_, this actually landed earlier this week but iirc you were asking about it:
[19:29] <charles> now when you dismiss an alarm, the audio stops as soon as the popup dialog goes away
[19:42]  * barry waves to slangasek 
[19:42]  * slangasek waves
[19:42] <barry> slangasek: so, you might not have the scrollback
[19:42] <slangasek> ok, apparently the new window being opened was correct, and I had fallen out of the channel :P
 robru: my build failed ^^ which isn't totally unexpected, but i'm
[19:43] <barry>         missing a button (or don't remember how) to retry the build  [15:14]
[19:43] <barry>  
[19:43] <slangasek> but at least there's http://irclogs.ubuntu.com/2014/07/18/%23ubuntu-ci-eng.html
[19:43] <barry> ah yes
[19:43] <slangasek> which is out of date
[19:43] <barry> heh
[19:43] <barry> sorry for the upcoming crappy paste
 barry, ok, depends -- do you have new commits to upload, or is it a
[19:43] <barry>         transient failure you want a no-change retry?  [15:15]
 robru: the latter
 (sometimes udm dbus just times out for reasons we've never been able
[19:43] <barry>         to track down)
 barry, ok, then you need to click through to the PPA, and find the ppa
[19:43] <barry>         build job and click retry there (citrain isn't even involved in that)
 well, once you do that, do a WATCH_ONLY citrain build job so that
[19:43] <barry>         citrain notices when the new rebuild completes  [15:16]
 yeah, there's no retry button.  must be some other permission issue
[19:44] <barry>         going on
[19:44] <barry>  
 barry, you're looking here?
[19:44] <barry>         https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-020/+build/6195265
 I see the retry button, not sure why you don't
 robru: yeah, me neither  [15:18]
 barry, ok, retried it for you
 what team are you in that i'm not in? :/
 thanks
 barry, probably ppa service team
 barry, https://launchpad.net/~ci-train-ppa-service
[19:44] <popey> ʘ‿ಠ
 pester asac for access to that  [15:19]
[19:44] <barry>  
 barry, anyway, now run the jenkins build job, but check WATCH_ONLY,
[19:44] <barry>         and then you'll get nice things like a queuebot ping when the new
[19:44] <barry>         rebuild is done
[19:44] <barry>  
[19:45] <barry> slangasek: ^^^
[19:45] <slangasek> robru: so you're agreed that the best interface for this (for the time being) is for people to click the retry button directly in the ppa?  I have no problem adding barry to the team, since he knows better than to bypass the train to upload to the ppa; but I don't want to add lots of people generally without training, and figure that "retry the build" is a thing it would be useful to be able to do
[19:46] <slangasek> barry: popey says: private paste ;)
[19:46] <popey> ☻
[19:46] <slangasek> robru: maybe this is enough of a corner case that I should not worry about it, though
[19:46] <barry> popey: you are so iconic
[19:48] <barry> yay.  failed again.  so it's a separate issue that udm sometimes times out, and i'll be getting together with mandel on monday to discuss.  of course, local builds don't fail :/
[19:50] <slangasek> ok
[19:52] <barry> slangasek: thanks :)
[19:57] <robru> slangasek, actually, for a while I was just doing jenkins rebuilds, which results in having the package re-uploaded. The personification of a very large number told me that doing that was very wasteful and the PPA retry build button was strongly preferrable.
[19:57]  * barry is back
[19:57] <slangasek> robru: right, exactly :)
[20:03] <robru> elopio, please approve the merges in silo 9 then I can publish
[20:04] <elopio> jhodapp: can you please top-approve them?
[20:04] <robru> kenvandine, hah, you published yourself, you sneaky core dev you.
[20:04] <kenvandine> robru, aren't i allowed to? :-p
[20:04] <robru> kenvandine, yup, just wasn't expecting it
[20:04] <jhodapp> elopio: got the links handy again?
[20:05] <kenvandine> ugh
[20:05] <robru> kenvandine, no, that's me
[20:05] <elopio> jhodapp: one second
[20:05] <robru> kenvandine, because I published at the same time you did
[20:05] <kenvandine> oh... hehe
[20:05] <kenvandine> ok
[20:05] <robru> kenvandine, your publish job ran fine
[20:06] <elopio> jhodapp: I think this is the only one that's missing the approval
[20:06] <elopio> https://code.launchpad.net/~brendan-donegan/mediaplayer-app/remove_scene_select_test/+merge/227071
[20:06] <kenvandine> robru, and when do we do the merge & clean?
[20:06] <elopio> robru: with the top-approval is enough, right?
[20:06] <slangasek> plars, fginther: where does the config logic live for the jenkins jobs that generate the source packages for silo uploads?
[20:06] <robru> elopio, no, I have to publish after the merges are top approved. it's not automatic
[20:06] <robru> kenvandine, after the package hits the release pocket
[20:07] <kenvandine> ok, i assume you'll do that?  i'll probably be eod by then :)
[20:07] <robru> kenvandine, so there's this script that polls the archive for that and pings us once it's ready to merge, but it's broken right now. i'm looking at fixing it
[20:07] <robru> kenvandine, yeah no worries
[20:07] <jhodapp> elopio: done
[20:07] <fginther> slangasek, I believe it's in lp:cupstream2distro, let me narrow it down
[20:07] <kenvandine> robru, cool thx!
[20:08] <elopio> robru: ready for you
[20:08] <slangasek> fginther: ok.  It came to my attention last weekend that the chroots are being updated in-line as part of each source package prep, and have not been updated since utopic opened; we could save a lot of clock time on jenkins jobs by making sure these base chroots were updated routinely
[20:09] <robru> elopio, jhodapp : uh, guys? https://code.launchpad.net/~brendan-donegan/mediaplayer-app/remove_scene_select_test/+merge/226863 this merge in the silo is superceded. did you want to maybe put the new merge in place and rebuild?
[20:10] <jhodapp> elopio: ?
[20:10] <robru> or did you just miss when you were trying to click approved?
[20:10] <jhodapp> robru: something changed
[20:11] <jhodapp> elopio: yeah, it has conflicts against trunk
[20:12] <robru> jhodapp, elopio: alright, well I'm gonna need you guys to find the new mp / sort out the conflicts, update the MP link in the spreadsheet, reconfigure, rebuild, retest, then I can publish.
[20:13] <jhodapp> robru: definitely... elopio: let me know when you want me to look again
[20:13] <fginther> slangasek, this appears to be the script to deploy the jobs: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/citrain/manual/setup-citrain
[20:13] <slangasek> fginther: thanks for the pointer
[20:14] <robru> fginther, hm? that's just the one that creates the jenkins jobs from the templates. it doesn't make the chroot. I don't know where that got done, maybe manually
[20:14] <robru> slangasek, ^
[20:14] <fginther> slangasek, I suspect you just want a new job to update the chroot daily. Which should just be a matter adding a new job to refresh to do just that
[20:14] <fginther> ugh, redundant
[20:15] <slangasek> fginther: ah, adding new jenkins jobs; this sounds like a task for someone who knows something about jenkins :)
[20:15] <fginther> robru, I don't think you want to generate a new chroot all of the time. I think it's enough to just update them
[20:16] <robru> fginther, right, but that script you linked neither creates nor updates the chroots, that's handled somewhere else, but I don't know where.
[20:16] <elopio> robru: wow, I think we were close :)
[20:17] <robru> elopio, yeah, not sure how that superceded merge slipped in there, or how it even built with merge conflicts.
[20:19] <elopio> robru: it was me who missed added the original one instead of the superceded. Sorry.
[20:19] <robru> elopio, no worries
[20:20] <fginther> robru, ok, so it's probably a 2 part task then, 1) create the script to update chroots if needed, 2) create jenkins job to call script
[20:21] <robru> fginther, yeah that sounds reasonable, except I don't have the first clue where those chroots are stored, what command will update them, etc. are we using pbuilder? i don't even know
[20:21] <kenvandine> mterry, kgunn: system-settings has been published, you can rebuild now
[20:21] <robru> mterry, kgunn nooooo
[20:22] <mterry> I'm getting mixed messages  :)
[20:22] <robru> kenvandine, the builds pull from trunk, you can't build until the silo is cleaned.
[20:22] <robru> publishing isn't enough
[20:22] <fginther> robru, it uses cowbuilder which I believe behaves just like pbuilder for the purpose of upgrading
[20:22] <robru> kenvandine, rather to be more clear, you can't rebuild the other silos until the first silo has been merged.
[20:24] <barry> i don't know any details about the chroots, but here's the script i use to keep my local chroots up-to-date: http://bazaar.launchpad.net/~barry/+junk/repotools/view/head:/chup
[20:24] <robru> barry, thanks
[20:26] <kenvandine> robru, ah... ok thx
[20:26] <elopio> robru: launchpad says there's a conflict, but I can merge that branch with trunk without problems.
[20:27] <robru> elopio, the warning about the merge conflict could be stale then. sometimes launchpad doesn't update the diff.
[20:27] <robru> elopio, at any rate, I can't publish that silo until all the merges are top-approved. so either approve that merge or replace it with one that is.
[20:31] <elopio> robru: I updated the line on the pending tab of the spreadsheet with the right MP
[20:31] <robru> elopio, ok you should be able to run the reconfigure job
[20:32] <elopio> which is not yet top-approved anyway. jhodapp, you just left your approve comment here: https://code.launchpad.net/~brendan-donegan/mediaplayer-app/remove_scene_select_test/+merge/227071
[20:32] <elopio> Please do it on the top.
[20:32] <robru> jhodapp, yeah, we like you on top.
[20:32] <elopio> :D
[20:33] <elopio> ok, reconfiguring.
[20:33] <jhodapp> elopio: can't, it has merge conflicts according to LP
[20:34] <elopio> jhodapp: I've just merged it with trunk here and there are no conflicts.
[20:34] <elopio> I'm not sure how to tell launchpad to refresh.
[20:34] <elopio> jhodapp: oh, you should have permissions to resubmit.
[20:34] <jhodapp> elopio: yeah that's odd, it doesn't show any conflicts in the diff either
[20:35] <jhodapp> elopio: k, resubmitted for you
[20:35] <elopio> that should clear it. I would have to reconfigure again, but that's fast.
[20:35] <robru> jhodapp, elopio: ok but if you've resubmitted Yet Another MP, you need to make sure the newest MP is in the spreadsheet and reconfig again
[20:35] <robru> yeah
[20:36] <elopio> it still says there are conflicts.
[20:36] <elopio> launchpad is drunk
[20:36] <bfiller> robru: could you please reconfigure silo 16? I added history-service
[20:38] <robru> bfiller, done
[20:38] <bfiller> robru: cheers
[20:39] <robru> bfiller, you're welcome
[20:39] <elopio> robru: if we ignore launchpad, will it merge fine when you publish?
[20:39] <robru> elopio, i imagine so... it doesn't merge in launchpad, it downloads trunk, downloads the branch, merges them, then pushes. so if there's no conflict it should work fine
[20:40] <elopio> jhodapp: sounds good? ^
[20:41] <jhodapp> elopio: worth a shot though I'd kind of like to know why it says there's a conflict
[20:42] <elopio> jhodapp: there used to be a conflict on debian/changelog on barry's branch.
[20:42] <elopio> but he solved it.
[20:44] <jhodapp> elopio: it's just kind of weird
[20:46] <elopio> I agree. But I tried merging the three to trunk, and there are no conflicts. Also merge trunk with the three in order.
[20:57] <elopio> oh, the resubmit needs a commit message.
[20:58] <tvoss> slangasek, charles seems like the silo is good to go for testing
[20:58] <tvoss> kgunn, ^
[20:58] <charles> tvoss, ack
[20:58] <charles> tvoss, 8?
[20:58] <tvoss> slangasek, charles, kgunn could you guys let me know your results?
[20:58] <tvoss> charles, yup
[20:58] <kgunn> yep
[20:58] <charles> yes
[21:00] <tvoss> kgunn, charles, slangasek just sent a mail
[21:32] <Laney> is there a general way to get ci train to substitute the version it's about to release?
[21:32] <Laney> in this case it's for a .maintscript file
[21:34] <kgunn> tvoss: looks good
[21:35] <robru> Laney, not sure what you mean? can you just write the .maintscript to parse the version out of the changelog? the built package will have the changelog.
[21:36] <Laney> no
[21:37] <Laney> The advice from dpkg-maintscript-helper(1) is to specify current-version~, but I don't know what the current version is going to be
[21:37] <Laney> guess I could just upload :-)
[21:38] <robru> Laney, you should be able to predict the current version, since it's just upstream+14.10.2014MMDD-0ubuntu1
[21:38] <robru> perhaps with a .1 in there if it's your second build of the day
[21:39] <robru> using UTC time
[21:39] <Laney> how do I know what MMDD are going to be?
[21:39] <barry> robru, slangasek third time's the charm: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-020/+build/6195265
[21:39] <Laney> I think there's some magic thing for symbols files
[21:39] <robru> Laney, right now in UTC. you're going to put the MP in a silo and build it right now, yeah?
[21:39] <Laney> that's a similar case
[21:40] <robru> Laney, there is a magic thing for symbols, but it isn't hooked up for maintscripts
[21:40] <Laney> nod
[21:40] <robru> Laney, how specific does the version have to be? Can you pick a MMDD that is greater than what's currently in the archive, but lower than what the next release will be?
[21:41] <robru> barry, cool, gonna publish then?
[21:41] <Laney> Maybe...
[21:42] <barry> robru: the dashboard hasn't caught up yet, but after that... much testing first!
[21:42] <robru> barry, ah, it polls on a 5min interval, should be done soon
[21:43] <barry> coolio
[21:43] <sil2100> robru: just to make sure - did you fix the issue already?
[21:44] <robru> sil2100, oh yeah, sorry. you deleted one too many lines, brought it back and redeployed, it's working now. forgot to email you
[21:44] <sil2100> Since I see that for some unknown reason  the check-publication-migration script is missing a line
[21:44] <sil2100> Yeah
[21:44] <sil2100> Thanks ;)
[21:44] <robru> sil2100, thought you'd be gone by now ;-)
[21:44] <sil2100> o/
[21:44] <robru> sil2100, have a good weekend
[21:45] <sil2100> I go now then ;)
[21:46] <robru> Laney, wait
[21:46] <robru> hahaha
[21:46]  * Laney wibbles
[21:46] <robru> Laney, just looking at the citrain code. it iterates over the files in debian/ looking for 0replaceme, but it skips files that don't contain 'symbols' in the name
[21:46] <robru> Laney, would be trivial to remove that check and do that substitution in all files
[21:47] <robru> Laney, although if I drop that check it'll make a changelog entry saying it updated symbols, might need a little more finesse than just dropping the check
[21:48] <Laney> does it replace with just the upstream version?
[21:48] <robru> Laney, yes it seems to replace with the upstream version
[21:48] <Laney> I need the full version, although I guess that's always just -0ubuntu1
[21:48] <robru> Laney, yeah
[21:49] <robru> Laney, you should be able to do 0replaceme-0ubuntu1
[21:49] <robru> Laney, want me to make this change? shouldn't be hard.
[21:50] <Laney> robru: That'd be nice, then we can try it out Monday
[21:50] <Laney> Can't think of any possible unintended consequences
[21:51] <robru> Laney, and if so, should I bother to check for "maintscript" in filename, or just do it for all files? do you envision any file under debian/* where you'd want a literal 0replaceme? it won't be escapable.
[21:51] <Laney> It's possible you'd want this in maintaner scripts too so I don't think I'd whitelist
[21:52] <robru> Laney, ok, I'll tinker and deploy something shortly
[21:52] <Laney> Probably best to deal with any bad stuff as it comes up, because I can't really think where it might atm
[21:52] <Laney> cool, cheers
[21:56] <robru> elopio, jhodapp ok now just approve that last merge ;-)
[21:58] <robru> mterry, kgunn: ok now you guys can rebuild your system settings
[22:01] <jhodapp> robru: cool...elopio, which MR is it?
[22:01] <robru> jhodapp, https://code.launchpad.net/~brendan-donegan/mediaplayer-app/remove_scene_select_test/+merge/227397
[22:01] <jhodapp> thanks
[22:02] <robru> jhodapp, you're welcome
[22:02] <jhodapp> robru: that makes me nervous that LP still says merge conflicts...I've not seen it wrong before
[22:03] <robru> jhodapp, that error doesn't even make sense. This merge doesn't even touch debian/changelog
[22:03] <kgunn> ta
[22:04] <jhodapp> robru: right, just sayin :)
[22:06] <jhodapp> elopio: robru: approved
[22:13] <robru> Laney, alright, I made that change and deployed in production, we'll find out soon if it explodes or not ;-)
[22:13] <cjwatson> Laney: The maintscript doesn't need to match exactly; a lower bound is sufficient
[22:13] <cjwatson> I would just put today's date in, and bump it if somebody else lands the package before you do
[22:13] <robru> Laney, as an added bonus, now when replacing 0replaceme, the changelog it generates will mention the specific filename changed, rather than just 'debian/*symbols' as it used to
[22:14] <robru> cjwatson, hah, too late! we support 0replaceme in in maintscripts now ;-)
[22:14] <cjwatson> I mean, if there's more automation, great, just worth understanding what the real constraints are too ...
[22:17] <Laney> cjwatson: Yes I know
[22:28] <Laney> robru: cheers I'll try it out next week
[22:28] <robru> Laney, you're welcome
[22:33] <robru> cjwatson, still around? need an archive-admin ack on some new binary packages https://ci-train.ubuntu.com/job/landing-012-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-scope-click_0.1+14.10.20140718.1-0ubuntu1.diff
[22:34] <cjwatson> huh, I thought we were having a call to talk about the design of that on Monday, so seems kinda premature
[22:34] <robru> cjwatson, dunno, blame alecu and mhr3
[22:36] <alecu> cjwatson: as I mentioned on the email thread, we're landing what we have so far; the call is to discuss ways to prepopulate that db, and any possible change.
[22:36] <cjwatson> robru: as an archive admin I have no objection; as a click developer I'm not so sure, but I guess this is unwindable
[22:37] <cjwatson> so go ahead
[22:37] <cjwatson> alecu: ok
[22:37] <alecu> great, thanks.
[22:37] <robru> cjwatson, alecu thanks
[22:38] <cjwatson> not around from here on though :)
[22:38] <alecu> have a great weekend :-)
[22:38] <cjwatson> ta
[22:38] <cjwatson> I'm sure I'll enjoy working on RTM bits in spare moments ;-)
[22:59] <bfiller> robru: need another reconfig on silo 16
[22:59] <bfiller> please
[23:00] <robru> bfiller, done: https://ci-train.ubuntu.com/job/prepare-silo/1086/console
[23:00] <bfiller> robru: thanks :)
[23:01] <robru> bfiller, you're welcome
[23:01] <bfiller> robru: if I'm only removing a package from the silo (history-service) do I still need to rebuild the whole silo before releasing?
[23:02] <robru> bfiller, nope, just need a WATCH-ONLY build (and for me to delete the package from the ppa)
[23:02] <bfiller> robru: ack
[23:02] <robru> which, it's not in the ppa, so you're good ;-)