[00:30] bregma, I tried assigning row 24 for you but the third mp in your list 404'd [00:43] bfiller, do you know what's going on in silo 12? I can't seem to publish it, it claims that the packages don't have the latest revisions from distro, but distro doesn't seem to have anything new in it... === psivaa_ is now known as psivaa-off [01:29] robru: so, no idea what is going on on silo 12 [01:29] boiko, ok, me either. I rebuilt everything because that's what the error message seemed to indicate it wanted me to do. no idea why though [01:30] robru: well, thanks for rebuilding it [01:31] boiko, you're welcome! i hope it works now... [01:38] boiko, oh well, it's published now [01:55] robru: nice, thanks! [01:55] boiko, you're welcome! [02:04] === trainguard: IMAGE 121 building (started: 20140709 02:05) === [02:28] robru, I fixed the errant MP from row 24 if you want to try again [02:29] bregma, good to go in silo 2 [02:29] ta [02:29] yw [02:31] bregma, oh, and http://people.canonical.com/~rbpark/citrain/#?q=bregma ;-) [02:57] robru: could you reconfigure 14 with the added MPs if you're still around? [02:59] cyphermox, done [03:01] ah crap [03:01] robru: cool thanks [03:01] cyphermox, you're welcome. what's wrong? [03:01] sorry for the noise, it was coming back to me now how to do this [03:01] cyphermox, yeah you gotta use the prepare job from the spreadsheet [03:02] yeah, and these things are all already in another silo :X [03:02] grr, I knew it was better to just land urfkill first and then do the rest [03:05] shiny, this is going to be fun to deal with [03:13] Wellark: please check with tvoss to approve https://code.launchpad.net/~kaijanmaki/dbus-cpp/read-only-properties-changed-fix/+merge/221839 and any other of the merges you provided me for flight mode [03:13] * cyphermox is going to bed [03:44] === trainguard: IMAGE 121 DONE (finished: 20140709 03:45) === [03:44] === changelog: http://people.canonical.com/~ogra/touch-image-stats/121.changes === [06:38] infinity: Can I ask you about this SRU? https://bugs.launchpad.net/ubuntu/+source/pygobject/+bug/1333512 [06:38] Ubuntu bug 1333512 in pygobject (Ubuntu Trusty) "Failing to import module breaks logging configurability and adds noise" [Undecided,In progress] [06:40] I was hoping to get an idea of when it might get accepted for Trusty? [06:41] veebers: 3 seconds ago. [06:42] veebers: Go forth and verify the build in proposed (once it happens). [06:50] sil2100, hey, can we land silo 4 ? [06:50] s/land/publish/ [06:51] infinity: awesome, thanks :-) [06:55] oSoMoN: I'm looking at it, but we need a packaging ack [06:55] Mirv, is there a link to the packaging diff? [06:56] Mirv, and who do you reckon could ack them? [06:56] oSoMoN: any core dev can ack them. there's no automated link for manually uploaded sources. [06:56] oSoMoN: this's the debian/ http://pastebin.ubuntu.com/7769054/ at least [06:58] I'm not entirely sure how to do this for such a big package, usually the automated diff for real Train packages contains also Makefile diffs etc. but that debian dir ack should probably be fine acked alone too. [06:58] obviously the maintainer change is not needed, but it's simply because I fixed it in my Qt 5.3 rebuild upload and the fix wasn't integrated back [06:58] oh, right, it also removes the changelog entry for the 5.3 rebuild [06:59] :/ [06:59] let’s not request a full rebuild just for a changelog entry, shall we? [07:00] I wouldn't, although I'd still hope that eventually there would be lp:oxide that can actually match the package (ie have packaging & all) [07:01] I mean: is there a way to avoid rebuilding the entire package (takes 4+ hrs on armhf) while fixing the changelog? [07:01] bzr isn't very scalable to oxide needs, though [07:01] no, there's no way to fix that manually. I don't mind me being erased from history, myself ;) [07:03] lool, hey, if you’re around, we’re trying to land version 1.1.0 of oxide (it’s in silo 4) and we need a packaging ack from a core-dev, changes are there: http://pastebin.ubuntu.com/7769054/ [07:08] thanks, let's see who we'll catch [07:12] probably all Germans have partied through the night or such [07:18] lool, nevermind, I got an ack from dholbach already [07:18] oSoMoN: the silo needs a juggle, but probably I can fix it the same way I fixed the other silo. it seems to me some indexes have been erased from the system or such. [07:18] I need to prepare silo (reconfigure) and watch only build [07:19] so I just wanted to say something before that scary error pops up :) resolving. [07:19] Mirv, not sure I understand exactly what’s going on, but if you say you can fix it, then go ahead :) [07:19] oSoMoN: it says version "0" now somewhere, for some reason [07:19] and errors out because of that, but refreshing seemed to help [07:21] sil2100: ^ you might be interested, since this is the second silo now where I get Version in ... (0) is not the last one prepared (real-version-number) [07:25] worked again [07:31] hmmm === cjwatson changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train Status: #119 promoted | CI Train Sheriff: cjwatson | Known issues: http://bit.ly/VI2SEl knows your silo status before the spreadsheet does. [08:11] i vaguely remember seeing an email about airline, something about verification of it. But i'm fuzzy on the details and can't find that email atm. [08:11] was there some email about it? and what is ci-engineering-airline? [08:12] It's still going through acceptance testing [08:12] I was doing some of that with click; got stalled on a bug [08:15] ok. Oh, and found the email. [08:18] Eisbrecher_xnox: ci-engineering-airline is the analogue of ci-train-ppa-service. Gotta have something to own the PPAs. [08:18] ack. [08:18] sil2100, so we're right back to where we started. that's really annoying [08:20] brendand: yeah... doubt we'll have a green image till the end of the week ;/ [08:20] brendand: what's up with those UITK failures? [08:20] unity8 seems to have crashed during the test [08:21] (during the UITK test) [08:21] ogra_, the dashboard is angry at what you did to brazil ;) [08:21] lol [08:22] sil2100, i can only hope all the issues we see are clear and reproducible [08:23] well i wonder if the unity8 crash will happen again if you re-run the UITK test [08:23] brendand: sil2100: it seems we lack the required app updates in the store at least to go with UITK [08:24] if it reproducable there is surely some issue ... [08:24] Mirv, probably that is true for most of the failures [08:24] Mirv: I thought popey already updated those [08:24] which ones were that, do we have a list ? [08:24] sil2100: yes he did (on #sdk) [08:24] popey: ^ right? You uploaded the required core apps for the new UITK, right? [08:25] so already two days ago [08:25] Mirv, i just don't want to see another issue like we had with webbrowser where it takes months to figure out what is happening [08:25] I updated the ones bzoltan asked me to [08:25] that just seemed like a logical explanation since there are eg. swipe/delete related failures [08:25] popey, i dont see updates since 118 [08:25] ogra_: yes, that was two days ago, when the apps were updated [08:26] oh [08:26] i thought they were supposed to go in alongside not ahead [08:26] it doesn't matter [08:26] k [08:26] i tested all of them on both my devel and proposed phones [08:26] to make sure existing users were not affected [08:31] ogra_: I'll be late 2-3 minutes [08:34] no worries, we're listening to music here [08:42] bzoltan, seems the sdk package test is failing again (checking for an obsolete transitional package) [08:43] ogra_: arghh... [08:43] http://ci.ubuntu.com/smokeng/utopic/touch/mako/121:20140709:20140709/8946/sdk/1348095/ [08:44] bzoltan: we discussed it already, we need to poke someone since it's using an old name for a package that doesn't exist anymore [08:44] Mirv: ogra_: I fix it in a sec [08:45] I think someone did some deserved archive cleaning just finally [08:45] thanks :) [08:47] Mirv: I deleted that package on 2014-03-14! [08:48] sil2100: can you reconfigure silo 14? [08:48] https://launchpad.net/ubuntu/trusty/armhf/libqt5graphicaleffects5 [08:48] ogra_: Mirv: I pushed the change... but the next natural step with that sdk tests would be to move to the real project and drop that obsolate for good [08:48] cjwatson: want to reconfigure that one? ^ You have to do it from the spreadsheet, find the row with the landing and do the same thing as while assigning [08:49] cjwatson: once a silo is assigned already, assigning it again opens up the reconfigure window [08:49] sil2100: I added notes-app to bug #1330352 where these swipe things were handled [08:49] bug 1330352 in notes-app "autopilot failure with SwipeToDeleteTestCase" [Undecided,New] https://launchpad.net/bugs/1330352 [08:50] and I'm getting a weird issue with silo 5 [08:50] 2014-07-09 08:49:50,925 ERROR Version in ci-train-ppa-service/landing-005 (0) is not the last one prepared (0.3+14.10.20140708-0ubuntu1) (direct upload?). [08:50] 2014-07-09 08:49:56,156 ERROR Some packages in the ppa are not at the latest version. Please rerun the prepare job, eventually only with that project. [08:51] sil2100: looking [08:51] Saviq, we seem to have a unity8 crash during the UITK tests (which makes a lot for the tests fail then) http://ci.ubuntu.com/smokeng/utopic/touch/mako/121:20140709:20140709/8946/ubuntuuitoolkit/ [08:51] brendand: see the 1330352 above too ^ [08:51] (not sure if it is even reproducable) [08:52] sil2100: newbie question, why does it need reconfiguring? Is it because it previously only contained urfkill? [08:52] rsalveti: which job produced that output? [08:53] cjwatson: silo 5 [08:53] just triggered a rebuild [08:53] said it was already built, but can't publish because it's not the latest version [08:53] rsalveti: I mean which URL to the jenkins console output [08:53] cjwatson: https://ci-train.ubuntu.com/job/landing-005-2-publish/50/console [08:54] === trainguard: IMAGE 122 building (started: 20140709 08:55) === [08:54] ogra_, lemme have a look [08:55] rsalveti: cjwatson: I found out earlier today with two silos there's something funky going on, train thinks a version is 0. I know how to fix it, though (no-op reconfigure + build with "watch_only") [08:55] it feels like some table got resetted or such [08:55] I'm wondering if it has anything to do with the recent change in LP PPA URL format [08:56] cjwatson: reconfigurations are needed when new merges and/or sources are added, since the backend doesn't fetch those from the google spreadsheet on build time but only during assignment [08:57] sil2100: this particular issue is the one I mentioned in the morning [08:57] sil2100: OK - where can I see what the backend currently has? [08:57] but hmm I think you discuss another thread here, ignore moe [08:57] cjwatson: most of the time the lander itself can reconfigure the silo, but whenever a new 'project' is added to the silo list, we actually have to reconfigure it for them [08:57] cjwatson: it's in the backend, let me find the link [08:57] sil2100: Does "09:53 -queuebot:#ubuntu-ci-eng- Silos: landing-014 (cyphermox) state is now 'Preparing packages' (connectivity-api, dbus-cpp, indicator-network, ubuntu-system-settings)" mean you already reconfigured? [08:57] cjwatson: http://people.canonical.com/~platform/citrain/ [08:58] cjwatson: I didn't reconfigure any silo right now, maybe Mirv did that? [08:58] Mirv: what was the exact case in the morning that you had? [08:58] no, I did not reconfigure anything but the ones I published [09:00] sil2100: well the one I pointed out at http://irclogs.ubuntu.com/2014/07/09/%23ubuntu-ci-eng.html#t07:21 and that ricardo is seeing above too [09:00] it seems mhr3 tried to build the silo [09:01] silo 14 [09:01] rsalveti: ubuntu-system-settings conflicts with silo 6; dbus-cpp conflicts with silo 8 (ignorable?); connectivity-api and indicator-network conflict with silo 11 [09:01] rsalveti, yep, i started the rebuild, anything wrong with that? [09:01] I saw that for both oxide and qtdeclarative silos, the version in PPA is thought to be 0 [09:02] mhr3: just because I was asking for it to be reconfigured, and it seems we also got a few conflicts [09:02] let me check the conflicts [09:02] rsalveti, oh, can you pls sync with Wellark then? [09:03] cjwatson: yeah, silo 11 also can be ignored for now from what the upstream developer mentioned [09:03] (but yeah, it's also our job to make sure the conflicts are sane and all parties know what's going on) [09:04] >>> from cupstream2distro import packagemanager [09:04] >>> packagemanager.get_current_version_for_series("goget-ubuntu-touch", "utopic", "ci-train-ppa-service/landing-005") [09:04] sil2100: cjwatson: yeah, the conflicts are all fine [09:04] u'0.3+14.10.20140709-0ubuntu1' [09:04] hmm [09:05] rsalveti: ok, I'll reconfigure harder [09:05] silo 6 is also in testing mode [09:05] done [09:06] thanks [09:07] reconfigure + build with watch_only checked fix both silos for me to be in publishable state again [09:08] sil2100: so just in case you see the similar error still with the other silos [09:11] ogra_, looks like a crash in Mir, uploading now [09:12] ah, cool [09:12] thanks for looking ! [09:12] Mirv,sil2100: hang on a bit, would like to investigate this centrally ... [09:12] I suspect this has to do with silos configured before the PPA URL format change [09:13] Oh [09:14] Though I'm not having any luck reproducing it [09:14] ogra_, nothing in .changes suggests any relation :| [09:15] no, it doesnt [09:15] Maybe it's best just to reconfigure/build-watch-only everything affected, but I'd like to hear about it if anything configured from now on shows this [09:15] ogra_, bug #1339610, let's see what a retrace comes up with and will make public then [09:15] Error: Launchpad bug 1339610 could not be found [09:15] https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1339610 [09:15] ubot5, yeah yeah [09:15] well, we had a new libhybris and accompanying android rebuild [09:15] but looking at the changelogs that shouldnt cause such issues [09:18] ok [09:19] I'll see about fixing up the silos that look like they may be affected by this and that aren't building or publishing at the moment - that's 3, 6, 7, 8, 11, 15, 18 [09:19] ogra_: no, minor change [09:19] Unless anyone thinks this is foolish? [09:19] changes [09:19] right [09:19] sil2100: ^- [09:22] cjwatson: seems fair, please do o/ === vila changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: vila | CI Train Status: #119 promoted | CI Train Sheriff: cjwatson | Known issues: http://bit.ly/VI2SEl knows your silo status before the spreadsheet does. [09:25] cjwatson: yeah, got the same issue on silo 5 [09:25] https://ci-train.ubuntu.com/job/landing-005-2-publish/51/console [09:26] rsalveti: will sort it [09:27] wish I could see the cupstream2distro bug, but whatever, this is good enough; not like the URL format's going to change every day :) [09:29] rsalveti: Try now? [09:29] (queuebot's a little behind) [09:29] I ran the watch-only build too [09:29] cjwatson: seems it finished fine now, thanks [09:29] Great [09:37] ogra_, humpf, retracer barfed :| [09:37] dang [09:37] ogra_, I'll try and see if I can repro locally [09:38] with all packages up to daye [09:38] date [09:40] ok, all should be fixed now apart from 0 (test), 1, 10, 19 (migrating) [09:40] if it affects m&c for any of the last three then I guess we force [09:45] sil2100: do merges need to be top-approved before we can assign silos? [09:47] cjwatson: normally, yes, but CI Train actually checks for that itself - it will allow a silo to be assigned but the lander won't be able to build anything if the merges are not approved [09:47] So you can assign a silo and CI Train will make sure they're approved before proceeding [09:47] ok [09:49] mhr3: This conflicts with silo 8 - assigning anyway since that's some way off ready, but please coordinate with tvoss [09:51] cjwatson, what doesn't conflict with 008? :) but yea, thx [09:51] Indeed [09:52] sil2100: So I did a first run of assignment for line 26, and got a conflict; I'd now like to run it again overriding that, but Landing team tools -> Assign to silo brings up a Reconfigure script which fails. Do I need to clear the request ID manually or something? [09:53] cjwatson: ah, there is a trick to that [09:54] cjwatson: so, just dismiss that pop-up, move to column number K of that landing and remove the UID generated there [09:54] cjwatson: and now you can run the assignment again [09:54] right, clear the request ID then [09:54] thanks [09:54] sil2100, not sure you saw the conversation above but it seems the UITK failures are Mir issues [09:55] cjwatson: the deal is: once you open the pop-up, until it's open you can assign the silo as long as you want, but if it gets closed and you want to 'assign' instead of 'reconfigure', you have to clear out the UID [09:55] rsalveti: hi, could you trigger a rebuild on silo 14.. there was an outdated version requirement to dbus-cpp on connectivity-api. fixed now. [09:55] (or rather the unity8 crash is a Mir issue and the UITK failures are fallout) [09:55] ogra_: Mir issues? We didn't have a new Mir upload since 0.4.0, now did we? [09:55] huh [09:55] sil2100: Got it, thanks [09:55] cjwatson: yw! [09:55] Wellark: I just triggered a build a few minutes ago [09:56] Wellark: do you want another rebuild after this one finishes? [09:56] sil2100, well, Mir causes unity8 to crash ... which in turn causes the failures [09:56] sil2100, bug 1339610 [09:56] bug 1339610 in Mir "unity8 crashed with SIGSEGV in mir::frontend::ClientBufferTracker::client_has()" [Undecided,Incomplete] https://launchpad.net/bugs/1339610 [10:00] rsalveti: gimme a sec. let's see how it goes. [10:03] ogra_: I guess we need to escalate that to the upstream, but it makes me wonder why it suddenly started happening after the UITK landing [10:04] And why not before [10:04] But I see Daniel already commented on the bug [10:05] sil2100, no idea ... but Saviq is on it [10:05] Ok, I jump out for that quick meeting with my old thesis supervisor [10:06] Be back soon [10:07] rsalveti: ok, please trigger a rebuild. [10:07] Wellark: ok [10:15] Wellark: done [10:16] can anyone reconfigure silo 6 for us? unity8-desktop-session was added [10:16] rsalveti, sympathies... [10:17] Saviq: yeah :-( [10:18] Saviq: looking [10:19] Saviq: conflicts with silo 2, please check with bregma [10:19] === trainguard: IMAGE 122 DONE (finished: 20140709 10:20) === [10:19] === changelog: http://people.canonical.com/~ogra/touch-image-stats/122.changes === [10:19] cjwatson, I'll coordinate, bregma will land his before ours [10:20] Saviq: ok, I'll add a note that yours needs to be rebuilt after his lands [10:20] cjwatson, yup, thanks [10:25] Saviq: ^- [10:25] cjwatson, thanks [10:25] ogra_, 269 tests OK on my phone [10:25] running again, but no high hopes [10:27] sil2100: I just got that welcome screen lock up on my mako again \o/ === vila changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train Status: #119 promoted | CI Train Sheriff: cjwatson | Known issues: http://bit.ly/VI2SEl knows your silo status before the spreadsheet does. [10:34] sil2100: oh I wonder if the Qt5 crash has anything to do with it :( [10:34] Mirv: ^ [10:45] hmm [10:46] cjwatson: hey, I'm getting strange error on silo 6: ERROR Some projects are missing their 'twin package' uploads (e.g. their -gles counter-parts): qtubuntu-gles. [10:46] cjwatson: seen that before? qtubuntu-gles is not a package name, qtubuntu-android is the right name for the package with gles support [10:47] greyback: qtubuntu-gles is the source package name - https://launchpad.net/ubuntu/+source/qtubuntu-gles [10:47] greyback, nope, that error is right ... [10:48] there are many ptubuntu packages with -gels equivalent that the emulator uses (gles support is a compile time switch atm ... so for the i386 emulator we needed to rebuild the packages with that enabled) [10:48] *qtubuntu [10:49] the -gles packages always need to be recompiled alongside thier nonn -gles equivalents [10:50] is it really exactly the same thing with a different flag? [10:50] yeah, the problem is that qtubuntu has qtubuntu-desktop and qtubuntu-gles [10:50] bzoltan: bug 1339616 and bug 1339627 reported against core apps after UITK landing. How come these weren't found during testing before landing? [10:50] bug 1339616 in Sudoku App "test_profiles fails on mako image #120" [Undecided,New] https://launchpad.net/bugs/1339616 [10:50] bug 1339627 in Ubuntu Calendar App "test_fill_form and test_add_new_event_with_default_values failed on mako image #120" [Undecided,New] https://launchpad.net/bugs/1339627 [10:50] so how do I proceed? [10:50] but what we need is qtubuntu-gles for x86 [10:51] and for that we need to build against a different qt (qt-gles) [10:51] that's why we have qtubuntu-gles [10:51] greyback: just need to sync the qtubuntu-gles package with your changes, and upload that to the silo [10:52] ok [10:52] Laney, it should be, yes [10:52] popey: for some reason I got false OK for these ... no idea how [10:53] ogra_: couldn't they be a single source which does multiple builds then? [10:53] Laney, it is a temporary solution that we can drop if the runtime detection of QT5 works right [10:53] popey: We have sent MRs for like 6 apps to fix tests... we could have done 8 [10:54] Laney, that would be a pretty complex package change (there are quite a few -gles packages) for a temporary hack that we plan to drop asap [10:57] yup, that's why we decided to do another src package for it [10:59] bzoltan, who gave the ok? [11:00] brendand: me [11:00] brendand: so it is only me to blame [11:02] ricmm: please let tvoss and mandel know to rebase silos 8 and 11 on top of yours, if you land before them [11:02] cjwatson, got it, he can land first, I'll rebase, not a big deal [11:02] bzoltan, there's no need to assign blame to anyone - just try and figure out where the process can be improved [11:03] cjwatson: ok, although we just decided to change the branch [11:03] ogra_, sil2100, second UITK run 269 OK [11:03] not sure if CI train scripts play well with utopic packaging branches [11:04] I doubt it [11:04] Saviq, yeah, i guess if you dont hit the crash you wont see failures in the tests [11:04] ogra_, yeah, no crash at all [11:04] right :( [11:04] like /var/crash *empty* [11:04] Well, since you're merging into lp:media-hub it should be OK actually, but better style to keep the namespaces separate [11:04] this doesn't happen too often [11:04] ogra_, sil2100, I say we monitor it [11:04] yup [11:05] 122 just started its test run ...lets see how it comes out === MacSlow is now known as MacSlow|lunch [11:06] can I get a reconf on silo 005 ? [11:07] sorry, bad timing :) [11:07] actually I can probably do that myself from jenkins [11:14] cjwatson: colin, could you configure 005 with force enabled? for the conflict [11:16] ricmm: the force flag would need to be on the build, not a reconfigure [11:16] ricmm: you don't have that checkbox? [11:17] ricmm: actually, I don't see a conflict, it's just an unapproved merge; you could get the merge approved? [11:17] cjwatson: yup its approved now, salveti said we'd need the force flag on configure [11:17] but if its on build, I can do it, thank you [11:18] yeah, I think that's all it needs === vila changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: vila | CI Train Status: #119 promoted | CI Train Sheriff: cjwatson | Known issues: http://bit.ly/VI2SEl knows your silo status before the spreadsheet does. [11:19] brendand: To run the full test suite locally on the device for the UITK is a very heavy process. Even in the best case it requires 8-10 runs, several reflashes, dozens of reboots and 4-6 hours with 3-7MB output. False failures and false OK results are expected at each run. [11:19] brendand: so missing 3 tests is actually not that bad [11:21] brendand: the real improvement would be to review and rewrite many app tests [11:33] bzoltan, we've done a lot of work on improving the stability of the test runs [11:34] bzoltan, so if you're still getting false failures then let us know about them, because we've certainly done our best to rid the CI dashboard of them [11:36] brendand: I can confirm that there is significant improvement. For real. It is way much better than it was before! [12:00] sil2100: who is looking after webapps while dbarth is on vacation? bug 1339686 [12:00] bug 1339686 in unity-webapps-gmail (Ubuntu) "App fails to load, apparmor error on mako #119" [Undecided,Confirmed] https://launchpad.net/bugs/1339686 === vila changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train Status: #119 promoted | CI Train Sheriff: cjwatson | Known issues: http://bit.ly/VI2SEl knows your silo status before the spreadsheet does. [12:01] popey: that is a valid question - dbarth didn't inform me of anyone filling in for him as a lander at least === cprov changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cprov | CI Train Status: #119 promoted | CI Train Sheriff: cjwatson | Known issues: http://bit.ly/VI2SEl knows your silo status before the spreadsheet does. [12:03] popey: but I guess alex-abreu and mardy should be around if anything [12:03] ok. === pete-woods is now known as pete-woods-lunch [12:04] silo 2 packaging changes look fine to me; publishing === alan_g is now known as alan_g|lunch === MacSlow|lunch is now known as MacSlow [12:18] bzoltan, good to hear, but it will really help us if when you are doing landings, you alert us of any issues with false failures [12:20] sil2100: did we miss our change to get this nice t-shirt done? [12:20] chance [12:21] or are we trying that for our next promotion run/iteration? [12:21] :) [12:21] asac: there's still chance, but it might take longer! [12:25] * asac will remember :) [12:26] sil2100, i think if we push hard and don't allow any more huge landings then we can do it by friday [12:26] sil2100, maybe with a bit of luck ;) [12:27] brendand: yeah... there's currently nothing big planned for this week, so I guess that's doable [12:28] sil2100, we just need to try and get these few new app failures fixed asap [12:28] brendand: did the SDK team now reproduce the sudoku/calendar ones locally? [12:29] Mirv, no - timp was just asking me if i did reproduce them locally [12:29] right [12:30] well, at least UITK passed in 122 [12:30] the timeout problems might be caused by UITK in some cases from what I've heard, but there's also still a change it's some combination of what went in to 120 that's giving the sudoku/calendar the trouble [12:32] brendand: during the last round I have experienced that for example the gallery app tests go crazy if they are run in a long sequence of tests. Also the UITK theme did not get installed with the plugin and that broke half of the app tests. It took some time to figure out. [12:35] brendand: the other silly bug what confused us before figuring out the workaround is that the phablet-click-test-setup must be run before adding the Silo ... otherwise the click tests can not be set up [12:37] brendand: plus the phablet-click-test-setup installs the stock UITK autopilot tests to the /home/phablet/autopilot and that overides the ubuntu-ui-toolkit-autopilot. So the ~/autopilot/ubuntuuitoolkit must be removed before the tests are run otherwise the new AP tests from the landing silo are not used and so many tests fail [12:38] brendand: also missing the `phablet-config autopilot --dbus-probe enable` after AP test configuration (or maybe after reboot) caused failures [12:38] bzoltan, oh - that shouldn't happen [12:38] bzoltan, a lot of these things are issues you should have faced before though [12:39] brendand: so these issues can easily waste 4-5 hours test rounds... nothing killing, mostly avoidable. But it is easy to miss out something and that delays the testing [12:39] bzoltan, is the process very manual? [12:39] brendand: these issues I am facing continuously [12:39] brendand: I have a script what I keep tuning ... [12:41] brendand: http://paste.ubuntu.com/7770080/ [12:43] brendand: it is one line on one out, one changed, few commented out ... every round I add few more paranoid and most likely unnecessary line :) You might say to this script that it is silly... but after all it works :) ... or not [12:45] bzoltan, what happens if one test fails, do you have a way to rerun just that test suite? [12:46] brendand: when a test fails usually I reboot and re-run, sometimes I even reflash and run it again on a clean device. I consider sure failure if it fails-fails-reboot-fails-fails-reflash-fails-fails ... [12:47] brendand: I rerun single test cases if there are only few... but if 10-20 fails I look for pattern and re-run the whole set. Sometimes when I suspect the UITK I re-run the test without the silo. [12:48] brendand: and I always save the test outputs, i have 15 log files from the previous landings [12:49] bzoltan, i can't help but think this would be much better to have in jenkins === alan_g|lunch is now known as alan_g [12:50] bzoltan, with all the traceability and you can run the tests in parallel on different devices [12:50] bzoltan, is it the case that elopio also helps you somewhat with this process? [12:51] brendand: Yes, i know.. i am lobbying for productizing the CI dash and assign one dash to each Silo with the defined test set according to the test plan [12:51] brendand: Ohh, absolutely .. I would be dead without elopio. He supports me in all way! [12:52] bzoltan, btw how aften are you releasing now? [12:53] brendand: :) it is a wrong time to ask that question. We had now 3 weeks without release. Normally it is weekly or at least every second week. [12:54] brendand: shorter the release cycle easier it gets [12:54] bzoltan, well of course [12:55] bzoltan, you should definitely have a consistent cycle, whatever its length [12:55] bzoltan, since the testing is mostly automated (even if it does take some time), one week should be realistic no? [12:56] brendand: the aim is the weekly release ... but sometimes single MRs take days to land on our staging branch, and few messed up verification round can waste days too [12:58] bzoltan, well don't you have a cut off point? so if a MR doesn't make it by a certain day then it doesn't get in that release? [13:00] brendand: it depends on the MR ... if it is a critical fix or an RTM related improvement then I wait for the MR or merge it to the landing branch [13:01] brendand: we have the trunk and we have a staging branch, I make the landing branch from the staging and sometimes I merge into that MRs what I know safe and important. But that is more an exception than a real practice === Ursinha changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: Ursinha | CI Train Status: #119 promoted | CI Train Sheriff: cjwatson | Known issues: http://bit.ly/VI2SEl knows your silo status before the spreadsheet does. [13:09] sil2100: I need to step out for an errand - should only take me 30-40 minutes === cjwatson changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: Ursinha | CI Train Status: #119 promoted | CI Train Sheriff: trainguards | Known issues: http://bit.ly/VI2SEl knows your silo status before the spreadsheet does. [13:11] cjwatson: no worries, I'm around if anything, battling some debhelper right now [13:13] Mirv, brendand, bzoltan I can reproduce the sudoku-app failure on my device https://pastebin.canonical.com/113193/ [13:14] t1mp: congrats ... me too [13:14] t1mp, good start. here's how it looked in 119: http://people.canonical.com/~brendan-donegan/sudoku.png [13:15] interesting [13:15] * t1mp checking whether positioning of dialogs changed === pete-woods-lunch is now known as pete-woods [13:18] brendand: what's the full name of the failing calendar_app tests? [13:18] so I can run those without running the full set of calendar_app tests [13:18] t1mp, it's in the bug [13:18] brendand: do you know if we have elopio around? he could be asked to check the notes-app swipe-left problem (bug #1330352) similar to the fixes he did on other apps [13:19] bug 1330352 in notes-app "autopilot failure with SwipeToDeleteTestCase" [Undecided,New] https://launchpad.net/bugs/1330352 [13:19] t1mp, autopilot list calendar_app and grep for the long name [13:19] I added notes there but I didn't assign it yet [13:20] Mirv, i thought swipe left was deprecated so the tests that test that explicitly should be deleted? [13:20] plars, the tests in 122 look suspiciously like a hanging mako ... didnt move since quite a while [13:21] brendand: yes, probably that's just the thing that should be done to notes [13:21] brendand: ok [13:22] t1mp, so for the sudoku one there seems to be a change in the layout of dialogs? [13:22] t1mp, the body of the dialog is appearing far down the screen [13:23] t1mp, http://people.canonical.com/~brendan-donegan/sudoku122.png as compared with the other screen [13:25] brendand: I don't know why this is happening, I don't see any recent changes to Dialog [13:26] t1mp, but you're going to figure it out, right ;) [13:27] ogra_: I'll take a look [13:36] brendand: I hope so :) the text and focus handling is complex with lots of workarounds that I am not yet familiar with [13:36] brendand: so I'm searching.. [13:38] ogra_: it was an unlock problem that caused other issues. I need to sort out how to isolate that better, preferably retry, and keep it from killing things in that way. It's running again now [13:49] why does phablet-test-run calendar_app work fine for me, but [13:49]