| === _salem is now known as salem_ | ||
| === blr_ is now known as blr | ||
| === jamesh_ is now known as jamesh | ||
| === chihchun_afk is now known as chihchun | ||
| morphis | robru: ping | 06:55 |
|---|---|---|
| morphis | robru: any idea why https://ci-train.ubuntu.com/job/ubuntu-landing-015-1-build/14/console fails even the needed dependencies are in the silo? | 06:55 |
| robru | morphis: you have a syntax error in your control file. I commented on the mp. | 06:57 |
| morphis | robru: oh really? | 07:16 |
| morphis | robru: which one? | 07:18 |
| robru | morphis: i can't remember, it was yesterday. Check your emails, there'sa review from me | 07:19 |
| morphis | robru: ah I see, thanks | 07:20 |
| robru | morphis: you're welcome | 07:20 |
| morphis | robru: but generally the source build should fetch the silo content, right? | 07:20 |
| robru | morphis: nope, why would it need to? Source build is basically just making a tarball. Build happens in ppa with deps | 07:21 |
| morphis | robru: yes, but I am introducing a new -dev package with a package already in the ppa | 07:24 |
| morphis | and those MP add the -dev dependency now | 07:24 |
| robru | morphis: i don't think it matters for source build. Try it out, if it doesn't work you'll just have to do it in two different silos | 07:25 |
| morphis | robru: ok | 07:26 |
| Mirv | I was also thinking it shouldn't matter but then I couldn't get past the error message complaining about missing package.. | 07:28 |
| morphis | robru: seems to work | 07:37 |
| morphis | Mirv: hard to see the dot against the comma when the display isn't the cleanest :-) | 07:37 |
| robru | Mirv: it wasn't complaining about a missing package, it was complaining about a syntax error | 07:37 |
| Mirv | morphis: robru: fun! | 07:43 |
| * Mirv cleans the display | 07:44 | |
| morphis | Mirv: :-) | 07:44 |
| === om26er_ is now known as om26er | ||
| morphis | robru, Mirv: now the build went through :-) | 08:32 |
| robru | Yay | 08:33 |
| john-mcaleely | sil2100, jibel I see that krillin device tarballs have qa granted (https://requests.ci-train.ubuntu.com/#/ticket/852 ) | 09:10 |
| john-mcaleely | is it ok to push them now? | 09:10 |
| sil2100 | john-mcaleely: fine with me! :) | 09:12 |
| jibel | john-mcaleely, works for me | 09:12 |
| john-mcaleely | ack, ack | 09:12 |
| === chihchun is now known as chihchun_afk | ||
| === ondra_ is now known as ondra | ||
| === chihchun_afk is now known as chihchun | ||
| Elleo | trainguards: any ideas what's happening with dbus daemon seeming to constantly die when running udm tests on vivid arm64 when running udm tests in silo 24? | 11:06 |
| john-mcaleely | sil2100, (some phone calls interrupted). krililn & vegetahd now pushed | 11:17 |
| Mirv | Elleo: let me retry the arm64 only (you shouldn't do full new builds just to rebuild one arch, but ping trainguards) | 11:22 |
| Mirv | Elleo: but if it continues to fail, it's probably a real arm64 vivid bug that won't get a fix since vivid development is basically stopped aside from phone | 11:22 |
| Mirv | Elleo: worked | 11:31 |
| Elleo | Mirv: great, thanks | 11:31 |
| === Trevinho|OFF is now known as Trevinho | ||
| rvr | mterry: ping | 13:15 |
| mterry | rvr, hello | 13:15 |
| rvr | mterry: Hey | 13:15 |
| rvr | mterry: I'm trying to reproduce this bug "Device can be tricked into exposing mtp service without being unlocked first" | 13:15 |
| rvr | mterry: When you say "Start to make an emergency call", do you mean the call itself or just entering the emergency screen? | 13:16 |
| mterry | rvr, just entering the emergency screen | 13:16 |
| rvr | mterry: I see. I can't reproduce it in OTA 8.5. | 13:16 |
| mterry | rvr, hrm. Let me try... | 13:18 |
| rvr | mterry: Oh, I can. | 13:18 |
| mterry | rvr, oh cool | 13:18 |
| rvr | mterry: And it's fixed in the silo. Thanks :) | 13:20 |
| mterry | rvr, yay! That's a nasty one | 13:20 |
| Elleo | jibel: silo 24 with the click reinstall regression now has a fix for the content-hub transfer breakage | 13:38 |
| jibel | Elleo, excellent, thanks! | 13:39 |
| Elleo | no problem :) | 13:40 |
| jhodapp | sil2100, ping | 13:47 |
| sil2100 | jhodapp: pong | 14:19 |
| jhodapp | sil2100, hey I am wanting to land this silo https://requests.ci-train.ubuntu.com/#/ticket/832 but I'm curious if that status means it's not ready to land yet...however when I pull the trunk branch there's nothing that it's missing from upstream | 14:20 |
| sil2100 | hmm | 14:31 |
| sil2100 | It's a strange situation | 14:31 |
| sil2100 | ah | 14:33 |
| sil2100 | jhodapp: ok, I think I know what's up | 14:37 |
| sil2100 | jhodapp: so... I don't think it's wise to release this branch | 14:38 |
| sil2100 | jhodapp: with tvoss's last landing qtubuntu-media is now dual-landable, and this silo only releases qtubuntu-media to vivid | 14:38 |
| jhodapp | sil2100, ok I was wondering if that might be the case...so basically reapply the changes to trunk and release that | 14:39 |
| sil2100 | jhodapp: yeah, releasing this wouldn't really revert any real changes, but it would just introduce new confusion to the fact from which branch to land | 14:39 |
| jhodapp | sil2100, ok | 14:39 |
| jhodapp | sil2100, thanks for looking at it | 14:40 |
| === chihchun is now known as chihchun_afk | ||
| ahayzen | sil2100, for the silo45, the code was rebased from lp:qtubuntu-media/stable to lp:qtubuntu-media, does the MP need to be retargeted ? or does the branch from the ~ci-train-bot go to the correct place due to the dual-landings stuff? | 15:09 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| sil2100 | ahayzen: hey! The merge needs to be retargetted and, to get the right changes inside, rebuilt as well | 15:29 |
| ahayzen | sil2100, ok thanks :-) jhodapp ^^ | 15:29 |
| jhodapp | sil2100, ahayzen thanks | 15:30 |
| jhodapp | davmor2, so for silos 36 and 45, which you already tested, we had to retarget them to trunk for dual landing since silo 22 landed which made qtubuntu-media dual landable. So, that means we had to reapprove the MRs...does this mean you want to test again before we land? | 15:57 |
| dobey | trainguards: can someone retry https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+build/8838366 please? | 16:06 |
| sil2100 | dobey: on it | 16:06 |
| dobey | sil2100: thanks | 16:06 |
| rvr | Saviq: ping | 16:19 |
| Saviq | rvr, hey | 16:21 |
| rvr | Saviq: Silo 30 | 16:21 |
| rvr | Saviq: I found an issue with camera app | 16:21 |
| rvr | Saviq: https://trello.com/c/nAccJ8Qd/2639-854-ubuntu-landing-030-gsettings-qt-unity8-qtmir-qtubuntu-saviq | 16:22 |
| Saviq | rvr, checking | 16:23 |
| Saviq | can't see how this silo could've influenced that | 16:24 |
| Saviq | it sounds more like the active/!active issue that was fixed before | 16:25 |
| Saviq | rvr, did you confirm this was not a problem without the silo? /me flashes krillin | 16:25 |
| rvr | Saviq: I'll check without the silo | 16:25 |
| Saviq | rvr, tried on a mako devel-proposed with silo 30, looks like camera got stuck completely | 16:28 |
| Saviq | and can't see the image in the msging app | 16:28 |
| Saviq | I mean it's black | 16:28 |
| rvr | Saviq: I can see the image, but the live view is black | 16:28 |
| Saviq | rvr, if you rotate the phone, does the button in camera app rotate (it might be devel-proposed's issue I'm seeing, waiting for krillin/rc-proposed to flash) | 16:29 |
| rvr | Saviq: Another problem, very hard to replicate, is that sometimes the apps won't start. | 16:30 |
| rvr | Saviq: For example, I closed the camera app, and now I'm trying to get a new image through the content hub, but camera app won't start. | 16:31 |
| Saviq | rvr, yeah I have the same now | 16:31 |
| Saviq | rvr, that I think might be our fault | 16:31 |
| Saviq | https://code.launchpad.net/~dandrader/qtmir/appRestart-lp1527737/+merge/281701 to be exact | 16:31 |
| rvr | But I also have seen it with System Settings | 16:31 |
| Saviq | rvr, can you confirm in ~/.cache/upstart/unity8.log prints like "Ignoring request as the application is closing and/or queued to start"? | 16:33 |
| rvr | qtmir.applications: ApplicationManager::onProcessStarting(appId="com.ubuntu.camera_camera") - User wants to start a new instance of an application that is still closing and is already queued to start later. | 16:33 |
| Saviq | rvr, can you see if you have the same for settings app? | 16:34 |
| rvr | qtmir.applications: ApplicationManager::onProcessStarting(appId="ubuntu-system-settings") - User wants to start a new instance of an application that is still closing and is already queued to start later. | 16:35 |
| jibel | rvr, can you check if the app is crashing when you get this message and try to start it? | 16:35 |
| jibel | rvr, it could be due to bug 1524131 | 16:35 |
| ubot5 | bug 1524131 in Canonical System Image "/usr/bin/mediaplayer-app:11:__memcpy_neon:std::char_traits:std::basic_streambuf:std::basic_streambuf:std::__ostream_write" [Critical,Confirmed] https://launchpad.net/bugs/1524131 | 16:35 |
| rvr | jibel: Yes, I have crashes for both camera app and system-settings | 16:35 |
| jibel | rvr, the app (any app not only mediaplayer) crashes, apport does it's job, and you try to restart the app but previous instance didn't yet stop running | 16:36 |
| Saviq | jibel, rvr, I doubt it, the crash is likely unity8 rejecting the app | 16:36 |
| Saviq | "UbuntuClientIntegration: connection to Mir server failed." | 16:37 |
| Saviq | rvr, ok, that one we need to fix, I will pull qtmir from the silo and have a look at the content hub exchange | 16:37 |
| rvr | Saviq: Ok | 16:38 |
| Saviq | rvr, thanks and sorry about that | 16:39 |
| rvr | Saviq: No problem | 16:39 |
| Saviq | rvr, I can confirm the black camera on krillin without the silo | 16:41 |
| rvr | Saviq: So different bug | 16:41 |
| Saviq | rvr, it actually crashed for me | 16:41 |
| Saviq | might be what uncovered the other issue | 16:42 |
| Saviq | and yeah, that's jibel's crash | 16:46 |
| Saviq | but it uncovered a problem in the qtmir change | 16:46 |
| Saviq | trainguards, please remove qtmir and qtmir-gles from silo 30 | 16:48 |
| sil2100 | Saviq: on it | 16:48 |
| Saviq | rvr, IMO after ↑↑ is done the silo is OK to go, the change was isolated in qtmir, and the camera app crash is what jibel mentioned | 16:49 |
| sil2100 | Saviq: removed | 16:50 |
| Saviq | sil2100, thanks | 16:50 |
| rvr | Saviq: Let me know when you have checked, and I'll redo the silo tests. | 16:50 |
| Saviq | rvr, Ready for QA | 17:11 |
| Saviq | I had the camera issue without the silo | 17:12 |
| rvr | Saviq: Me too | 17:12 |
| Saviq | and behaves the same with silo | 17:12 |
| Saviq | I mean without qtmir it behaves the same now with silo as without it | 17:12 |
| Saviq | rvr, FWIW your re-test really doesn't need to be a full one, qtmir was definitely the broken change and everything else was fine IIUC? | 17:13 |
| rvr | Saviq: Yes, everything else was fine. | 17:13 |
| Saviq | rvr, black image after content hub seems to be a xenial issue then | 17:17 |
| rvr | I created a bug report for the black camera issue https://bugs.launchpad.net/canonical-devices-system-image/+bug/1533292 | 17:19 |
| ubot5 | Launchpad bug 1533292 in Canonical System Image "Black screen after switching from camera-app" [Undecided,New] | 17:19 |
| rvr | jibel: ^ | 17:20 |
| jibel | rvr, I think this is known | 17:20 |
| jibel | hm, maybe not | 17:22 |
| rvr | jibel: In OTA 8.5, camera app closes when the image is returned to the messaging app | 17:24 |
| rvr | So something has changed | 17:24 |
| jibel | rvr, the camera must be launched before you start the test? | 17:29 |
| jibel | rvr, I cannot reproduce your case | 17:29 |
| rvr | jibel: Nope | 17:31 |
| rvr | jibel: I start the messaging app, tap to new message | 17:32 |
| rvr | jibel: tap to get an image, select camera app, take a photo | 17:32 |
| rvr | jibel: tap the tick button to return the image to messaging app | 17:32 |
| jibel | rvr, yeah, that's what I did, I definitely cannot reproduce. I'll reflash | 17:33 |
| rvr | jibel: In rc-proposed, I can switch back to camera app, but it's in black | 17:34 |
| rvr | jibel: In OTA 8.4, I cannot switch back to camera app, it is closed | 17:34 |
| rvr | 8.5 | 17:34 |
| jibel | rvr, on rc-proposed the camera app closes when I tap the tick | 17:34 |
| rvr | jibel: Hmmmmmm... krillin or arale? | 17:35 |
| jibel | rvr, both | 17:35 |
| rvr | o_O | 17:36 |
| rvr | Trying in krillin | 17:36 |
| rvr | jibel: I can reproduce it in krillin | 17:37 |
| rvr | current build number: 227 | 17:37 |
| rvr | device name: krillin | 17:37 |
| rvr | channel: ubuntu-touch/rc-proposed/bq-aquaris.en | 17:37 |
| jibel | rvr, I'm reflahsing the krillin | 17:38 |
| rvr | camera-app eventually crashes, but I won't call that a proper "close" | 17:38 |
| === alan_g is now known as alan_g|EOD | ||
| jhodapp | jibel, ping | 18:43 |
| Saviq | rvr, jibel, that's likely why it doesn't close, it crashes and stays around until apport does its thing | 19:03 |
| Saviq | but is stuck all that time, you can see by the panel being on screen and button not rotating when you rotate the phone | 19:04 |
| awe_ | robru, looks like the old ps-jenkins, and now ci-train-bot seems to leave old ofono merge branches in development state after merging. It's probably due to the way the project was setup. Just wanted to check with you first before I manually clean them up ( ie. by changing status to 'Merged' )? | 19:13 |
| awe_ | https://code.launchpad.net/ofono | 19:13 |
| robru | awe_: setting branches as merged is launchpad's job, nothing to do with the train. if they don't say merged then I highly doubt they've been merged. | 19:16 |
| awe_ | take a look | 19:16 |
| awe_ | I think it's the way the train merges things | 19:16 |
| awe_ | or as I said, how we set things up for ofono | 19:16 |
| awe_ | the packages were definitely released | 19:16 |
| awe_ | by CI | 19:17 |
| robru | awe_: what I'm seeing is a lot of branches that have dozens of commits that are not in lp:ofono | 19:17 |
| awe_ | lp:ofono is not our upstream | 19:17 |
| awe_ | lp:~phablet-team/ofono/ubuntu | 19:17 |
| robru | awe_: well then that might explain it then | 19:17 |
| awe_ | the commits did get merged in that branch, as expected | 19:18 |
| awe_ | I'm not sure if it's possible and/or worth fixing it so that the right thing happens for future merges. I just wanted to change the status of the branches manually without first *asking*. | 19:19 |
| awe_ | ;D | 19:19 |
| robru | awe_: i guess you need to make lp:ofono be the development target and then lp will automatically recognize that stuff has been merged and mark it as such | 19:26 |
| robru | awe_: I'm not really familiar with the details, all I know is that this Just Works for everybody else and I've never had to care about it before today | 19:26 |
| awe_ | I don't want to do that ( at least not right now ). So if you have no objects to me just changing the status on those branches to 'Merged' manually, we'll leave it at that | 19:27 |
| robru | awe_: sure | 19:27 |
| awe_ | k | 19:27 |
| awe_ | thanks | 19:27 |
| robru | yw | 19:27 |
| jhodapp | jibel, for silos 36 and 45, davmor2 already tested them for landing only in vivid but I had to re-merge against trunk due to silo 22 landing which enabled qtubuntu-media to be dual landing. Does davmor2 need to retest the silos even though he already approved them? | 19:49 |
| robru | bblunh | 20:13 |
| robru | *bblunch | 20:13 |
| === salem_ is now known as _salem | ||
| cjwatson | awe_,robru: Right, when a branch is pushed, LP looks through all merge proposals that have that branch as their target, and for each such MP, if the tip revision of the target branch has the tip revision of the source branch as an ancestor, then it's marked as merged. | 20:59 |
| cjwatson | There's some refinement around that but that's basically it. | 20:59 |
| robru | cjwatson: is there any reason that would only work when the target is lp:foo instead of lp:~team/foo/bar ? | 21:04 |
| robru | attente: just run the 'build' job to generate that diff ^ | 21:05 |
| cjwatson | robru: not in general; perhaps the merge target is simply wrong | 21:06 |
| robru | cjwatson: dunno, he said he confirmed the source branches are merged in the target branch he wants to use | 21:07 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| robru | cjwatson: hm actually I guess none of these are being marked as merged. odd https://code.launchpad.net/~ci-train-bot | 21:12 |
| robru | cjwatson: oh you know what it is? train doesn't "merge" the branches, it just pushes them to the destination. maybe that's why? | 21:13 |
| dobey | robru: the ~ci-train-bot branches don't have MPs | 21:13 |
| robru | dobey: that might explain a thing or two | 21:14 |
| dobey | robru: so yes, it's just pushing one branch to another destination; that will not result in the branch being pushed from as 'merged' just as when you branch lp:foo and push it to lp:~user/foo/bar lp:foo doesn't have its status changed | 21:15 |
| dobey | robru: if the ~ci-train-bot branches are meant to be temprorary things for the silo builds, the "clean and merge" stuff should probably delete them after pushing to the target | 21:16 |
| robru | dobey: oh, you think deleting is the way to go? I assumed they had some forensic value for keeping around. | 21:17 |
| attente | this is a new source package, so i'm not sure what the diff would look like other than the whole source package | 21:17 |
| dobey | robru: well, if you want to keep them around, i guess manually set the status to Merged on it | 21:17 |
| robru | attente: in that case the diff will just be blank but the train is fussy about having that so please run the build job. | 21:18 |
| attente | ok | 21:18 |
| attente | do i need to specify any of these options for generating the diff? | 21:18 |
| cjwatson | robru: that still involves the tip of the source being in the target's ancestry (trivially) | 21:18 |
| cjwatson | but if there are no MPs, that ends up being rather different. anyway, on a call | 21:19 |
| robru | attente: no just run the build job with no options. the options are mostly for recovering from various errors that happen, first time you run it is almost always all blank. | 21:19 |
| dobey | awe_, robru: so yeah, the landing-XXX branches hanging around is not related to the project setup. it's a CI train issue | 21:24 |
| robru | curse you dobey! I was happy to blame it on awe_ | 21:25 |
| dobey | lol | 21:25 |
| dobey | robru: well, if you just avoided pushing those things to launchpad, and used tarmac to do the merging, it wouldn't be an issue ;) | 21:26 |
| === blr_ is now known as blr | ||
| awe_ | robru, lol | 22:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!