[02:04] === trainguards: IMAGE 19 building (started: 20141113 02:05) === [03:24] === trainguards: IMAGE 19 DONE (finished: 20141113 03:25) === [03:24] === changelog: http://people.canonical.com/~ogra/touch-image-stats/19.changes === === cprov__ is now known as cprov_ === nik90_ is now known as nik90 === chihchun_afk is now known as chihchun [05:19] mornings === verterok` is now known as verterok === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [10:29] trainguards: hey, can silo 6 be published, please? [10:57] ping, any trainguards around? [11:00] oSoMoN: o/ [11:00] publishing [11:02] Mirv, note that there are packaging changes, they have already been acked by kenvandine [11:02] Mirv, see his approval here: https://code.launchpad.net/~osomon/webbrowser-app/sanity-unit-tests/+merge/241543 [11:03] oSoMoN: oh, excellent, I was just about to ping og_ra on them [11:03] heh [11:03] oSoMoN: that doesn't include the autopilot dep changes though [11:03] ah, right, it doesn’t indeed [11:03] ogra_ to the rescue? ;) [11:04] yes. ogra_ : https://ci-train.ubuntu.com/job/ubuntu-landing-006-2-publish/37/artifact/packaging_changes_webbrowser-app_0.23+15.04.20141113-0ubuntu1.diff [11:04] looks correct, autopilot-touch depends on python3-autopilot plus autopilot-qt5 which depends on libautopilot-qt [11:04] hmm, i hate that i cant see which section these changes are in [11:04] ogra_: https://code.launchpad.net/~osomon/webbrowser-app/depend-on-autopilot-touch/+merge/240039 [11:05] yeah, doesnt help :P [11:05] well that of course doesn't help :D [11:05] I agree, it's annoying [11:05] (same diff) [11:05] you can guess since you see the first line of description... [11:05] yup, it would be cool to be able to display the entire file in launchpad’s diffs [11:08] ok, took a bit (dug up the complete file from the branch) ... [11:08] ACK [11:08] ACK [11:10] oSoMoN: Could you file a bug on Launchpad itself suggesting that, please? I had a quick look and nothing similar appears to have been filed already. [11:11] cjwatson, sure, will do [11:17] ogra_, Mirv: thanks! [11:19] lp timed out when trying to file a bug against it :/ [11:19] now it got through [11:19] cjwatson, bug #1392282 [11:20] bug 1392282 in Launchpad itself "Feature request: show entire file in diffs generated for merge requests" [Undecided,New] https://launchpad.net/bugs/1392282 [11:20] it just wants to make you think twice ;) [11:21] or it’s a clever way of devising the perfect product: no bug reports, no bugs :) [11:23] oSoMoN: thanks [11:23] timeout> oops id or it didn't happen :) [11:23] darn, I close the page, didn’t keep the oops id at hand [11:23] s/close/closed/ [11:24] (but it might just be one of the gazillion problems that will be fixed once the new database servers are installed) === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [11:42] slangasek: We need your eyes on the new qtbase candidate which brings the multiarch cross supporting qmake [11:43] slangasek: there's a debdiff of Zoltan's work at https://launchpadlibrarian.net/190250795/qtbase-opensource-src_5.3.2%2Bdfsg-4ubuntu2_5.3.2%2Bdfsg-4ubuntu3~vivid1~test1.diff.gz (don't mind the changelog stuff, I'd do a proper build after there's agreement on the method) [11:48] Mirv: nice, that looks pretty straightforward === greyback__ is now known as greyback === alan_g is now known as alan_g|lunch [13:25] robru: hi, would you mind reconfiguring vivid silo 22 again? I had to add one more MR to it [13:33] boiko: he's not awake for 3.5h more hours, but I'm here for a bit still [13:34] Mirv: ah ok, would you mind reconfiguring the silo then? [13:37] boiko: yep already done [13:37] Mirv: thanks! === karni is now known as karni-lunch === alan_g|lunch is now known as alan_g [14:05] Hello! [14:06] Dropped in for a moment to check how things are going [14:06] I see the landing gates are closed already? [14:06] Any topblockers remaining? :) [14:07] silDroid, sure, lots [14:07] silDroid, but we have a ggood RC candidate [14:07] looks like we'll make it for tomorrow promotion ;) [14:07] No waaay! [14:07] processes processes processes ;) [14:07] * ogra_ does the ballemt [14:08] *ballmer [14:09] Anyway, great news, thanks for handling this guys [14:21] My turn in the queue, good luck everyone and keep on rocking! [14:21] See you later ;) [14:21] o/ [15:03] ogra_: do I need to bribe you these days for silos? [15:04] or Mirv and rsalveti still good candidates? [15:04] * sergiusens wants one for line 72 [15:04] should be a quick one [15:04] I can do it [15:04] sergiusens, Mirv and robru are the trainguards [15:04] i do the landing tea, duties beyond that [15:04] *team too :P [15:04] sergiusens: silo 6 [15:05] ogra_: so you are above everyone? sort of like a manager :-P [15:05] rsalveti: thanks [15:05] kind of ... the amount of meetings i have agrees === karni-lunch is now known as karni [15:38] ogra_: one landing tea for me, please! [15:38] * ogra_ goes brewing :) [15:38] * Mirv likes fast service [15:39] cihelp: we (uss team) are having some issues with the otto test runner e.g. [1]. Tests are failing, then timing out, then a Java error. Any clues as to why this happens? Thanks! :) [1] https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-vivid/109/consoleFull [15:47] ogra_: you don't do landing coffees man you're a drinkist who knew === alan_g is now known as alan_g|tea [15:51] davmor2, lol, for myself i only do coffees :) but there is a missus here in the house too ;) [15:52] ogra_: oh you mean there is a boss in the house right ;) [15:52] yeah :) === alan_g|tea is now known as alan_g [16:05] jgdx, I'll take a look. First question I have, are these desktop tests providing useful results over the tests that are running on touch? [16:15] fginther, yes, they have so far. === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [17:24] trainguards: can I have a silo for line 73? [17:25] robru, you around ? [17:27] slangasek: ping [17:28] bzoltan: hi [17:29] slangasek: would you have few secs to check my change proposal for the qtbase packaging? [17:30] slangasek: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-016 [17:30] slangasek: details -> https://code.launchpad.net/~bzoltan/kubuntu-packaging/qt5-qmake-cross-armhf/+merge/241568 [17:31] slangasek: this will enable the SDK to use the x86 qmake binary with the armhf dev packages... namingly enable the qmake project types in multiarch click chroots [17:35] bzoltan: currently on a call, sorry [17:35] slangasek: no worries :) pong me when you have few minutes for me [17:53] ogra_: hey what's up? [17:53] jdstrand: rtm 2 [17:54] robru: thanks! [17:54] jdstrand: you're welcome [17:56] robru, just wanted to know if you are there since you werent at the meeting ... (i would have looked for another llander for the US TZ then) [18:02] ogra_: ah sorry, just missed my alarm. I'm around now if you need me to handle anything === alan_g is now known as alan_g|EOD [18:08] robru, no, all fine ... RTM is still frozen hard anyway [18:13] ogra_, it's starting to look like this MTP issue is real [18:14] brendand_, hmm, hwo long/often do i need to connect to actually see it [18:14] (i tried three times since the meeting and cant manage to get it) [18:15] ogra_, you have to leave the device disconnected for a little while [18:15] bah ... and saying that ... [18:15] i did [18:15] three times [18:15] and just tried again now [18:15] and got it :( [18:16] ogra_, and i rolled back to 151 and couldn't get it [18:16] brendand_, but [18:17] brendand_, http://paste.ubuntu.com/8991048/ [18:17] this is clearly a hos issue [18:17] *host [18:17] please check your PC logs [18:17] ogra_, which log was that? [18:17] dmesg on my laptop [18:20] there is either something going on on kernel level on the device or on driver level on the PC [18:21] ogra_, i actually get http://paste.ubuntu.com/8991087/ [18:21] ogra_, so what's the deal with it working on 151 then? [18:21] brendand_, that log looks fine [18:21] and i have to take back everything i said ... my screen was locked [18:21] * ogra_ slaps forehead [18:22] ogra_, are you looking the directory i told you or seeing what nautilus is doing? [18:22] brendand_, not yet ... i was double clicking nautilus and noticed it didnt open the device [18:22] then checked my dmesg [18:22] ogra_, didn't open at all? [18:22] but indeed you need to unlock the screen before connecting [18:23] totally forgot about that [18:23] ogra_, well you can unlock after too [18:23] right [18:23] ogra_, if the phone is locked then there will be something in 'ls $XDG_RUNTIME_DIR/gvfs' but nothing in that directory [18:24] confirmed [18:24] ogra_, if it's unlocked then you will see directories for the Internal storage and SD card [18:24] ogra_, unless you get the bug described then there will be nothing in gvfs [18:25] right [18:25] ogra_, davmor2 confirmed independently [18:25] ogra_: it's true sorry I blame you, brendand_ is nice and blames cyphermox [18:26] phablet@ubuntu-phablet:~$ status mtp-server [18:26] mtp-server stop/waiting [18:26] thats probably the reason [18:26] ogra_, yeah that would be it i guess [18:26] ogra_, but why did it stop? there's no crash file [18:27] yep, a "start mtp-server" and re-plugging fixes it [18:27] no crash file ... [18:28] ogra_, indeed [18:28] ogra_, well we can't expect our users to know to do that [18:28] ogra_, obviously [18:28] ogra_, so you can confirm it too then? [18:28] yes [18:28] ogra_, obviously :) [18:28] just looking at the last changes [18:28] ogra_, silo 18 was about mtp [18:29] ogra_, landed around 155/156 [18:29] yes [18:29] http://launchpadlibrarian.net/190012631/mtp_0.0.4%2B14.10.20140909~rtm-0ubuntu1_0.0.4%2B15.04.20141104~rtm-0ubuntu1.diff.gz [18:29] oops [18:30] LP fooled me [18:30] http://launchpadlibrarian.net/189438431/mtp_0.0.4%2B15.04.20141103~rtm-0ubuntu1_0.0.4%2B15.04.20141104~rtm-0ubuntu1.diff.gz [18:30] thats the right diff [18:32] cyphermox, why did we add all this dbus stuff instead of blantly make it sleep 10 sec ? [18:32] olli, so thats pretty bad news :( [18:33] where? [18:33] ogra_, well we just need to get a fix and retest it tomorrow [18:33] ogra_, what [18:33] cyphermox, in pre-start of mtp-server ... [18:33] olli, mtp is broken [18:33] olli, we found a bug where mtp stops working if you leave the device disconnected for a little while [18:34] olli, it's a regression from the last promotion [18:34] brendand_, so you think just atomic testing is enough for that ? [18:34] no full re-test needed ? [18:34] ogra_, of the whole image? if that's the only thing that lands? [18:35] brendand_, well ... (silent sigh) .... slangasek uploaded his livecd-rootfs change ... so shorts will be gone (which is wanted but adds another diff) [18:35] pmcgowan, ^ [18:35] brendand_, i assume thats no biggie though [18:35] ogra_, :/ this is why things need to be actually frozen [18:36] brendand_, yes, i only saw the upload today when checking rtm-changes [18:36] ogra_, anyway we found the bug, now we need to deal with it [18:36] brendand_, right, i was fearing a full re-test run [18:36] if we can handle that atomic then it is fine [18:36] ogra_, if a full retest is really warranted then we might do that [18:36] ogra_, not sure if jibel is around but it's probably up to him [18:37] * brendand_ needs to go make dinner [18:37] i'll come back later to find out what's happening [18:37] if the change impacts the upstart job of mtp-server only, I tihnk it's safe to re-run the sanity tests + regressions tests of mtp [18:37] ogra_, we might want to discuss whether it makes sense to pursue the promotion or not [18:38] +to discuss whether [18:38] olli, well, if we can just do an atomic re-test of the change we are still on schedule [18:38] seems QA thinks thats possible [18:38] ogra_, however there is the livecd-rootfs change. [18:39] jibel, which just removed the shorts .click [18:39] jibel, i could also temporary roll that one back for this one build and re-land it [18:39] if that makes you feel better (though i generally trust slangasek's code usually) [18:40] ogra_: hey, question for you. I need to test some changes to the way the train builds source packages. the one I've chosen at random for testing takes a little while to build and is slowing my ability to iterate. Can you think of any source packages which we normally release through the train which is just a super trivial package that can be built [18:40] near-instantly? [18:40] jibel, http://launchpadlibrarian.net/190258118/livecd-rootfs_2.257_2.257%2Brtm.1.diff.gz [18:40] ogra_, yeah expect the unexpected [18:40] ok [18:40] easy to roll back [18:40] if needed [18:41] robru, hmm [18:41] robru, ubuntu-touch-session is only processing .install files iirc [18:41] ogra_: thanks [18:42] ogra_: what's the argument for rolling back livecd-rootfs? I was told this needed to be out for RTM [18:43] slangasek, we are in a hard freeze for RC [18:43] and there are no code changes here, just adding one click to the exclusion list [18:43] slangasek, and we found a regression that wequires us to re-roll [18:43] slangasek, right, i think jibel agrees [18:43] ogra_: ok [18:44] slangasek, and if disagreement comes up i'll take care to temporarily revert that (but dropping one click wont do harm to testing imho) [18:46] ogra_: mtp isn't broken, it's unnecessary to add straight sleep and sleep if the greeter is already available [18:47] ogra_: this definitely isn't brendand_'s issue if it works for a while and later stops [18:47] hmm, k [18:48] cyphermox, the gadget is fine too ... else adb wouldnt work straight away ... and it wasnt broken in 151 which was tested for several days [18:49] well, for some reason the usb device fails after a while, this has nothing to do with dbus or upstart [18:50] right, but it didnt happen a few images ago ... must be something recent [18:51] yes, we should find what recent change made this fail [18:51] or if it's something that has always been the case, just never noticed before [18:52] ogra_, pls let me know the final verdict [18:52] brendand_: is there nothing in syslog? [18:52] olli, yeah, seems we dont know what causes it :( [18:52] again, aborting and rerouting QA efforts is a valid option in my books [18:52] or when it started [18:53] cyphermox, well, mtp-server iis clearly not running when this happens [18:53] olli, re-routing ? [18:53] what we discussed earlier, regression/promotion vs silo testing [18:53] olli, that would mean another three days for an image before we can promote [18:54] ogra_: it wouldn't be if the usb device got reset [18:54] ogra_, understood [18:54] since it would have to be re-tested from scratch [18:54] ogra_, all I am saying is that we should discuss how to proceed when we know what's up with mtp [18:54] olli, the way they want to do it is to fix the issue and validate on top of the tested one ... that way we can still be on time (if a fix is found tonight) [18:54] ogra_: is there nothing in syslog that indicates the usb device got reset? [18:55] ogra_, understood, this is assuming it's a contained fix [18:55] so, let's see what the issue is [18:56] cyphermox, there is some gadget noise, but i'm not sure thats not just the plug/unplug of the cable http://paste.ubuntu.com/8991493/ [18:57] and it isnt unusual [18:58] is it? [18:58] gadget: high-speed config #1: android is a plug event [18:58] try yourself [19:00] working on it. [19:00] wait a second [19:00] brendand_: what computer are you using for this? [19:01] are you plugging in to USB 2.0 or USB 3.0 ports? [19:01] [3630479.605545] usb 2-1.4.3.1: new high-speed USB device number 31 using ehci-pci [19:02] i'm in 2.0 here [19:02] yeah, figured [19:02] oh [19:02] wait [19:02] lol [19:02] I'm probably never going to be able to reproduce this with this computer, I need to get the other, just a minute. [19:02] * ogra_ uses not the terminal logged into his desktop this time :P [19:02] [532498.720830] usb 3-1: new high-speed USB device number 19 using xhci_hcd [19:02] 3.0 [19:03] cyphermox, what i dont get is that adb stays rock stable while this happens [19:03] and is that the computer on which you're able to reproduce the issue? [19:03] the gadget doesnt get reset [19:03] yes [19:03] the gadget doesn't, but the usb device might [19:04] E1113 19:59:21.748877 6737 MtpServer.cpp:174] request read returned -1: Input/output error [5] [19:04] I1113 19:59:22.480207 6768 server.cpp:419] MTP server starting... [19:04] thats from mtp-server.log [19:04] I know [19:04] but i guess you have seen that already [19:04] how does MtpServer.cpp talk to the device ? [19:04] any dbus involved ? [19:04] (i guess not) [19:05] how would there be? [19:05] it's straight USB [19:05] right [19:06] that's why you get I/O errors, at some point you're trying to read from the device, but it got reset or something, so that read fails [19:06] how about suspended ? [19:06] (but why would adb not be suspended then) [19:06] and then you're probably hitting that multiple times while as you plug in, the device is trying to settle [19:07] right, you get the upstart event from the plug [19:07] because adb never gets stopped, it just runs, no? [19:07] right [19:07] so upstart likely gives up on mtp-server after a while [19:07] well, adb needs the gadget available [19:07] I'd like to try respawn limit unlimited after I'm done trying to reproduce this bug [19:07] it dies if it isnt there [19:07] the gadget is available [19:08] seven minutes to go [19:08] ? [19:09] https://bugs.launchpad.net/ubuntu/+source/mtp/+bug/1392405 steps to reproduce [19:09] Launchpad bug 1392405 in mtp (Ubuntu) "MTP device cannot be mounted after some time" [Undecided,Confirmed] [19:10] heh, i didnt time it for that long [19:12] nah, it doesn't have to be that long [19:12] cyphermox, no i just asked davmor2 to do 15 minutes to make sure [19:12] it's not necessary to wait that long [19:12] cyphermox, i've had it happen after much shorter periods of time [19:12] it's usb, nothing is timed [19:13] cyphermox, this is my syslog at the time mtp log says it first failed http://pastebin.ubuntu.com/8991687/ [19:13] its krillin, you never know :P [19:13] thats from my mako, I can check the other they are both with the issue [19:14] trying something, now I just need to wait two minutes so I can actually see the difference in timestamps in the logs [19:14] cyphermox: I just put in the steps I followed for it to work [19:14] I have a fix ready [19:14] cyphermox, \o/ [19:14] this wouldn't be some new bug though [19:14] but a new manifestation [19:15] not even [19:15] just new people noticing it [19:15] lol [19:15] that would be owrrying though [19:15] *worrying too [19:16] given these same people test every image [19:16] they don't always test the same way the exact same things [19:16] cyphermox, no - it doesn't happen on 151 [19:16] and there's a bit of luck involved [19:16] brendand_, you won the lottery ;) [19:18] yeah, seems better [19:21] ogra_: yeah but when you test the image it's one test after another the phone isn't idle for long so it wouldn't show up :) [19:22] cyphermox, it's recent and not luck [19:22] jibel: it's debatable. The only reason you weren't seeing this while the previous version was in use is that it would fail before you'd get to that point [19:22] davmor2, yeah, we need to add some long time tests perhaps [19:22] and before that, you still had the same issue [19:23] ogra_: not to the sanity tests, the idea there is they are quick not long :P [19:23] davmor2, i bet you nnever hit the UI hang either in normal testing ... typically only something you see after long time usage [19:24] ogra_: indeed I think you spout rubbish when you go on about these hangs ;) [19:24] haha [19:24] ogra_, I see that error in a log I have from Monday if that means anything [19:25] pmcgowan, what error ? [19:25] pmcgowan: how should we proceed to land the fix, silo as per usual, or skip some steps and upload somewhere else? [19:25] E1110 11:56:05.048171 2794 MtpServer.cpp:169] request read returned -1: Input/output error [5] [19:26] cyphermox, silo per usual [19:27] cyphermox, right, silo it, have davmor2, brendand_ or jibel test and sign off the silo and i'll roll an image once it landed [19:27] cyphermox, do you understand when it was introduced or revealed? [19:27] pmcgowan, ah, i thought you referred to the syslog paste :) [19:27] it's probably from the first version of mtp ever released, just got hidden by the previous greeter issue [19:27] ogra_, sorry no the mtp server log [19:28] ah right, the greeter messages go away then [19:28] if someone could appropriate bless https://bugs.launchpad.net/ubuntu/+source/mtp/+bug/1392405 that would be helpful [19:28] Launchpad bug 1392405 in mtp (Ubuntu) "MTP device cannot be mounted after some time" [Undecided,Confirmed] [19:29] pmcgowan, olli ^^ [19:29] on it [19:29] * ogra_ looks at the MP [19:29] ogra_: want to review https://code.launchpad.net/~mathieu-tl/mtp/lp1392405/+merge/241733 ? [19:29] ah, yeah [19:29] cyphermox, to slow, already approved :P [19:30] ack [19:30] robru: can I haz a silo for line 74 please? [19:30] can you silo it yourself ? [19:30] or that :) [19:30] ah, actually I could just assign it myself [19:30] yeah [19:30] vivid first, then rtm [19:30] tsk [19:31] ah, I see, spreadshett issue for me [19:32] cyphermox: need help? [19:32] cyphermox: my mouse cursor has gone invisible for some reason so I'm totally flying blind right now... [19:32] cyphermox, doesnt it already try to restart for a full 30 secs? [19:32] maybe, just waiting for google to let me refresh [19:33] yeah spreadsheet seems down [19:33] robru: I think I'm good now, I'll do the assign myself [19:33] cyphermox: coo [19:33] oh wait, no [19:33] l [19:33] well, one day [19:37] alright, silo 15 [19:38] cyphermox, thx for the quick fix [19:40] cyphermox, can you explain a bit how this will fix it, it seems it tried a long time to respawn even now [19:40] ogra_, if that's the remedy, then I think we are all +1 on your & QA's proposal of continueing with business as usual [19:40] olli, right, let QA sign off the fix in the silo first :) [19:41] ogra_, just early unblocking the best case scenario [19:41] yep [19:41] pmcgowan: what do you mean? [19:41] i just want to see QA give a thumbs up for the fix [19:41] it's not about time but about the number of tries [19:42] cyphermox, sure but why wouldnt it restart within 30 secs [19:42] I'm not sure where you get the 30 seconds from [19:43] mtp runs when usb is connected, and stop when usb is disconnected, it's really only that [19:43] but as you connect or disconnect it, there is a short period of time where the usb device might come up and down a few times as it gets ready [19:43] and that's what is causing the issue [19:44] if it does that while mtp is starting (or stopping, really), eventually upstart would give up trying to restart mtp-server since it appears to not be useful [19:44] cyphermox, if I look at my mtp server log I see it try to start over a period of 30 secs, unlesss I read it wrong [19:52] pmcgowan: I see what you mean now, indeed it's no longer being stopped at all. *sigh* [20:01] cyphermox, ogra_should we revert that last upstart change? [20:01] no [20:01] pmcgowan, no, it will fix it [20:01] or work around it [20:04] I never touched the server low-level read code before, that will need to be improved but it will take longer to fix [20:05] for what we're trying to do now, the upstart fix will do the job [20:08] ogra_, cyphermox, no witchhunt, but do we know whether this is a regression and if so, when it slipped in [20:08] it's not a regression, it has always been an issue, or at least easily since last year [20:08] olli, no, this has been broken since day one, the recent change just exposes it more [20:09] olli, there is some issue with how mtp talks to USB === chihchun is now known as chihchun_afk [20:15] robru: ^ [20:46] cyphermox, hmm, was there any reason to not land in parallel ? [20:47] * ogra_ fears we wont have QA people alive anymore one the rtm silo is availabel for signoff [20:47] nothing is truly in parallel, stuff just gets synced [20:47] should have just dput'ed to both silos and manually megred the branch :) [20:47] robru: can you poke like 75 appropriately so things work? [20:47] ogra_, cyphermox what's the ETA for the rtm silo? [20:48] jibel, well, as long as it now takes to assign an rtm silo and build (plus a short test i guess) [20:49] 30min ? 1h at most i would hope [20:49] it shouldn't even take that long [20:49] jgdx, current round of otto issues have been resolved. A rerun of the MP you pointed me to is now passing - https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-vivid/115/ [20:57] cyphermox, well, depends if it ever starts :P [20:57] robru: ping [20:58] heh [20:59] ok, rtm 13 [20:59] now to copy [21:00] cyphermox: When the mtp upstart silo is ready, I'll take it. [21:00] just dupt the vivid source package worst case [21:00]