| dobey | ToyKeeper: ok, i'm going to hop off now. i'll check back in a bit, so please ping/sms me if you have any problems/questions. thanks :) | 00:01 |
|---|---|---|
| ToyKeeper | Have a good evening. | 00:01 |
| jamesh | "chroot problem": that's a new error for me: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-075/+build/9060234 | 02:10 |
| jamesh | Now it looks like the arm64 builds have gone crazy :( -- been running for an hour each, when they usually took a fraction of that time | 03:18 |
| dobey | ToyKeeper: any luck? | 03:22 |
| ToyKeeper | dobey: Getting there, but have been sidetracked by other unrelated issues in this latest image. | 03:45 |
| dobey | oh ok | 03:46 |
| dobey | just wanted to check in before heading off to sleep. saw no updates on trello and no pings for me, so thought i'd ping just to check. :) | 03:52 |
| ToyKeeper | dobey: Aside from staging issues, it was fine when I last tested. Today things have been much less agreeable, and it seems due to bugs in the new base image. | 03:52 |
| dobey | hmm | 03:53 |
| ToyKeeper | (arale rc-proposed 255) | 03:54 |
| dobey | i don't have an arale here. but i was able to purchase the other day on my mako just fine, after dealing with a couple of apparent oddities of the base image | 03:56 |
| dobey | those oddities seem to have been fixed now though | 03:56 |
| ToyKeeper | This image is ... odd. Oddities is a good word. | 03:56 |
| dobey | what problems are you hitting that are blocking your testing of IAP? | 03:57 |
| dobey | hmm, maybe i spoke too soon. might have to file some bugs in the morning. need a decent way to record the screen on the phone to an .mpeg or something | 04:01 |
| dobey | well i guess i should go get some sleep for now | 04:06 |
| dobey | night | 04:06 |
| ToyKeeper | My favorite kind of problems, it seems... ones which happen inconsistently. :( | 04:06 |
| ToyKeeper | Anyway, I'll keep at it. | 04:06 |
| ToyKeeper | dobey: Sometimes nothing happens if I tap 'install' when no U1 account is defined. Sometimes if I cancel buying vowels, they are granted anyway. | 04:13 |
| ToyKeeper | ... and the image must have had some pretty bad other bugs land in the past day or two, but those are unrelated. | 04:14 |
| bzoltan | jibel: \o/ the silo50 is now good, I managed to fix the s390x build too. | 04:41 |
| jamesh | is the indicator tray transparent for anyone else? | 07:36 |
| jibel | bzoltan, great, thanks for fixing it. We'll review it asap. | 08:05 |
| karni | Hi folks. I'd like to ask for ci-train perms for my buddy, Jin Hsieh (lp: jin.cth) | 08:54 |
| karni | yo jin | 08:55 |
| jin | karni: hey mate ;) | 08:55 |
| davmor2 | karni: I am now | 09:04 |
| === chihchun_afk is now known as chihchun | ||
| karni | davmor2: HI :) | 09:23 |
| karni | davmor2: question. I just filed a first request for Telegram QA pass through ci train | 09:23 |
| karni | davmor2: I submitted, and I'm wondering if should change the "Lander Signoff" to 'Approved'? | 09:24 |
| karni | davmor2: what's that field responsible for? | 09:24 |
| davmor2 | karni: sil2100 is the one for citrain stuff ^ | 09:24 |
| karni | jibel: got a questio above ↑ I recall you helped with Telegram QA a while back | 09:25 |
| davmor2 | karni: not sure how it works for click apps | 09:25 |
| karni | davmor2: yeah, I believe we indicate "Manual download URL" and that's it | 09:25 |
| sil2100 | karni: yeah, I suppose that's the way to go :) The QA process for clicks is a bit different, but I think jibel's bot will then pick it up | 09:25 |
| karni | I just want to make sure this request gets processed, and not "filed, but inactive" because I did something wrong :D | 09:25 |
| karni | sweet \o/ | 09:25 |
| karni | I guess we're set then :) Thanks guys! | 09:25 |
| davmor2 | karni: and set qa ready | 09:26 |
| karni | davmor2: sorry? /anything I need to set?/ | 09:26 |
| davmor2 | karni: what's the ticket number | 09:27 |
| karni | https://requests.ci-train.ubuntu.com/#/ticket/1044 | 09:27 |
| karni | we'd also like to get ci-train permissions for jin | 09:28 |
| davmor2 | karni: like that | 09:28 |
| karni | davmor2: \o/ question - do I need to ask you to change this for me each time I file a ticket? | 09:28 |
| karni | davmor2: or when I file it, it's just in queue for you guys | 09:29 |
| sil2100 | karni: what's the persons exact LP username? | 09:29 |
| karni | sil2100: jin.cth | 09:29 |
| karni | sil2100: thank you! :) | 09:29 |
| davmor2 | karni: no that is something you set, so you do set approved for lander and then when it is ready for QA to actually test (i.e. all the landing have happened) you switch the qa to ready | 09:29 |
| jin | sil2100: jin.cth @Karni, thanks | 09:29 |
| sil2100 | np! | 09:29 |
| karni | davmor2: perfect | 09:30 |
| karni | davmor2: so if I have no dependencies, I simply do 'lander approved' and 'ready for qa' | 09:30 |
| sil2100 | jin: you should be added to the right team, you'll probably have to relog into the CI Train interface | 09:30 |
| davmor2 | karni: you need to add that url thingy so it tricks billeto I think but yes | 09:31 |
| karni | davmor2: url thingy? you mean manual download url? | 09:32 |
| jin | sil2100: thanks, now i can create the new request from that | 09:32 |
| davmor2 | karni: that's the one I couldn't think of the name on the field | 09:32 |
| karni | ok | 09:33 |
| davmor2 | karni, jin: and then as a final confirmation you can go to https://trello.com/b/AE3swczu/qa-testing-requests-for-questions-ping-ubuntu-qa-on-ubuntu-ci-eng and ensure a ticket is created (can take about 5 minute iirc) | 09:33 |
| karni | davmor2: good suggestion, thank you | 09:34 |
| jin | davmor2: thanks! | 09:37 |
| === chihchun is now known as chihchun_afk | ||
| === vrruiz_ is now known as rvr | ||
| === Chipaca` is now known as Chipaca | ||
| Saviq | trainguards, can you please drop unity-api, qtubuntu, qtubuntu-gles and ubuntu-system-settings from silo 64, thanks :[ | 10:49 |
| sil2100 | uh oh | 10:54 |
| sil2100 | That's a lot of packages! | 10:54 |
| sil2100 | On it | 10:54 |
| sil2100 | Saviq: removed from the PPA | 10:55 |
| Saviq | sil2100, thank you | 10:55 |
| Saviq | sil2100, oh sorry, ubuntu-themes, too | 11:00 |
| sil2100 | Saviq: done | 11:01 |
| Saviq | thanks | 11:01 |
| === _salem is now known as salem_ | ||
| anpok_ | trainguards: can we somehow retrigger only the arm64-xenial build in a silo? | 14:00 |
| Saviq | anpok_, trainguards can | 14:06 |
| Saviq | anpok_, directly in the PPA if you tell them which one | 14:06 |
| anpok_ | trainguards: please retrigger in landing ppa 32 the mir arm64 xenial build | 14:08 |
| cjwatson | anpok_: done | 14:12 |
| cjwatson | (that's https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-032/+build/9062094) | 14:12 |
| anpok_ | cjwatson: thanks | 14:14 |
| rvr | oSoMoN: ping | 14:49 |
| oSoMoN | rvr, pong | 14:49 |
| rvr | oSoMoN: Hi, I'm testing silo 70 | 14:50 |
| oSoMoN | just seen that, thanks | 14:50 |
| rvr | oSoMoN: I'm checking Esc manually | 14:50 |
| oSoMoN | and it’s been fast-tracked, that’s cool | 14:50 |
| rvr | oSoMoN: Yes, we are doing that for low-risk silos :) | 14:50 |
| oSoMoN | rvr, so the fix in that silo fixes only the third test that’s mentioned in https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1546627 , the other 3 will be fixed by the next UITK landing | 14:51 |
| rvr | oSoMoN: In finding page and in address bar, after pressing Esc nothing happens | 14:51 |
| ubot5` | Launchpad bug 1546627 in webbrowser-app (Ubuntu) "4 autopilot test failures (related to ESC key) on desktop" [High,In progress] | 14:51 |
| oSoMoN | rvr, yup, that’s the fix in the UITK, nothing we can do to work around it in the browser | 14:51 |
| rvr | oSoMoN: Ah, so it's an issue with the UITK | 14:52 |
| oSoMoN | rvr, my branch was merged into the staging branch of the UITK, so I guess it will be in the next UITK landing | 14:52 |
| rvr | Ok | 14:52 |
| oSoMoN | rvr, it’s two issues really, one in the UITK, and one in the browser, and silo 70 addresses only the browser part | 14:52 |
| jibel | oSoMoN, we are experimenting with a way to land some silos with less manual QA. in particular silo well covered by automated tests, with a low failure rate or no failure at all in the past landings, ... it's just an experiment to see how we could define some rules | 14:53 |
| oSoMoN | jibel, I +1 this experiment, and whatever happens I’ll try to keep the quality of browser landings high | 14:54 |
| rvr | oSoMoN: Silo approved, keep up the good work! :) | 14:55 |
| oSoMoN | rvr, thx | 14:55 |
| oSoMoN | rvr, note that silo 16 will need to be rebuilt before you can test it | 14:56 |
| jdstrand | sil2100: I see that 9.1 has all the security fixes. thanks! | 14:56 |
| jdstrand | of course, we have some new ones for oxide, but they'll just flow in | 14:56 |
| rvr | oSoMoN: Oh, ok! | 14:56 |
| oSoMoN | I wasn’t sure which of the two you would validate first, which is why they were kept both in the queue until now | 14:57 |
| rvr | I'll keep an eye, but let us know when it is ready | 14:57 |
| Saviq | plars, hey, I was wondering, is lp:ubuntu-test-cases/touch something we should be using for interfacing with devices from heymann? for provisioning, that is? I'm worried that in case we pop up an unbootable image, all the devices will get b0rked, and everyone will need to cater for their own devices (i.e. make them stick to a known-bootable image, for example) | 15:22 |
| plars | Saviq: I don't recommend that branch as I don't think any team maintains it now. You may want to use the device management and recovery bits that I ripped out of it though, which is now in lp:lifeboat | 15:27 |
| plars | Saviq: did you see the examples of using it for getting your adb-id, and recovering bricked devices? | 15:28 |
| Saviq | plars, yeah, but recovering bricked devices is one thing, if you flash it with an unbootable just after ;) | 15:29 |
| plars | Saviq: https://wiki.canonical.com/InformationInfrastructure/Jenkaas/ExampleJobsAdbList and https://wiki.canonical.com/InformationInfrastructure/Jenkaas/ExampleJobsPhoneRecovery | 15:29 |
| plars | Saviq: what do you mean? | 15:29 |
| plars | Saviq: if you flash an unbootable image to it, that recovery tool will get you back to a bootable image (an older one of course). From there, you can try something else | 15:30 |
| Saviq | plars, sure, that's manual, though | 15:30 |
| plars | you'll at least be able to talk to it with adb, tell it to reset to fastboot, etc | 15:30 |
| plars | Saviq: no, it's all automated | 15:30 |
| Saviq | plars, wait | 15:30 |
| Saviq | plars, to run tests, people will flash the devices with rc-proposed and/or devel-proposed | 15:31 |
| Saviq | plars, sure, recovery will help to recover the device, but it will flash a broken image straight after, so no testing can happen anyway | 15:31 |
| plars | Saviq: I recommend using the recover tool at the beginning of your job, so you can get it in the best state possible. If it's already reachable, it will just leave it alone. Otherwise it will try to reboot it. If all else fails, it will install a known-good image on it. From there, you can use the phablet-tools and u-d-f to put whatever you want on it | 15:32 |
| Saviq | plars, well that's the problem - "whatever I want" might be broken | 15:32 |
| plars | Saviq: well right, if they flash a bad image, then the very first test (booting) failed and we don't need to run more tests :) | 15:32 |
| plars | Saviq: I guess I don't understand the question... you want to run tests on an image that won't boot? | 15:33 |
| Saviq | hrm | 15:33 |
| Saviq | plars, no, I want to flash a known-good image in that situation | 15:33 |
| Saviq | plars, ideally so that there's a central notion of what is a known-good image | 15:33 |
| plars | Saviq: that's what the recover tool does | 15:34 |
| Saviq | plars, but we can't use that to test, it's too old | 15:34 |
| plars | Saviq: it may not be a recent known-good image (in fact it probably won't be) | 15:34 |
| plars | Saviq: you could install the last image you successfully tested from there, I suppose. But if you already tested that image, why do you want to just repeat that? | 15:35 |
| Saviq | plars, because I'm not testing the image | 15:35 |
| Saviq | plars, I'm testing stuff that I put on top of it | 15:35 |
| plars | Saviq: does this happen a lot? | 15:36 |
| plars | Saviq: maybe qa maintains such a list? | 15:36 |
| Saviq | plars, it hasn't happened for a while :) | 15:36 |
| Saviq | but when it did way back when, it wroke havoc | 15:37 |
| plars | in theory, it should never happen, or at least be very rare | 15:37 |
| Saviq | plars, right, maybe I'm preempting too much, let's see how we do ;) | 15:37 |
| plars | Saviq: if it becomes an issue, then it's probably worth talking to QA and sil2100. Perhaps there could be some kind of promotion within that channel, or an untested channel that gets boot testing at least before promotion to devel-proposed | 15:38 |
| Saviq | plars, yeah I think that's kinda what devel is meant to be | 15:39 |
| plars | Saviq: yes, and then someone will want boot testing before it gets to that channel :) | 15:39 |
| sil2100 | We promote devel-proposed images to devel basically on such smoke-testing | 15:42 |
| sil2100 | e.g. jibel checks if the image boots, if the shell is starting, if networking is available and if he can adb into it I guess | 15:42 |
| plars | I thought that used to be the case, not sure what happens today | 15:44 |
| plars | good to know something like that still occurs | 15:44 |
| jibel | what's missing is the automated promotion. currently it's me telling to sil2100 that it's good to promote | 15:44 |
| plars | ah | 15:44 |
| plars | lp:auto-jibel | 15:45 |
| plars | :-D | 15:45 |
| jibel | + silbot2100 | 15:45 |
| plars | haha | 15:45 |
| sil2100 | ;p | 15:49 |
| * sil2100 goes back to being AFK | 15:50 | |
| davmor2 | sil2100: meeting/ | 17:05 |
| === alan_g is now known as alan_g|EOD | ||
| dobey | oh joy | 18:40 |
| Saviq | plars, hey, I'm afraid I might've b0rked krillin-07, apparently --wipe and --developer-mode / --recovery-image don't play well, needs to be --bootstrap after all :/ | 23:00 |
| Saviq | plars, oh it recovered, must've been flashing longer than I expected :) | 23:02 |
| plars | Saviq: great! | 23:03 |
| Saviq | plars, on that note, do you still have devices available in the lab? I could use a second phone to run autopilot for rc and devel in parallel | 23:03 |
| plars | Saviq: possibly, but there aren't many. Send a request to the ce-certification-qa@lists.canonical.com list please so I have it documented and I'll check into it | 23:06 |
| Saviq | plars, great, thanks | 23:07 |
| dobey | ToyKeeper: hey; you can repeat the "got the vowels anyway on canceled purchase" ? | 23:11 |
| ToyKeeper | dobey: Sure. I was wondering if you'd have a new build for me. :) | 23:11 |
| dobey | ToyKeeper: can you do it again and watch ~/.cache/upstart/dbus.log and ~/.cache/upstart/application-click-org-qtproject-qthangman.kaijanmaki_org.qtproject.qthangman_0.3.log for errors? | 23:12 |
| ToyKeeper | dobey: Sorry about all these delays, too. I'm not usually involved with silos these days but it seems nobody else wanted this one. | 23:13 |
| dobey | ToyKeeper: i think it might be an issue with your account on the server perhaps. | 23:13 |
| Saviq | plars, oh but krillin-07 indeed flashed in non-developer mode, so need someone to unlock the screen... https://unity8-jenkins.ubuntu.com/job/run-commands/582/console :( | 23:15 |
| dobey | ToyKeeper: i have hit that issue before, but it was a problem with the server now allowing the client to acknowledge the purchase for some reason. i thought it had been fixed, but maybe an issue with your account on staging. | 23:15 |
| * Saviq files a bug with u-d-f | 23:15 | |
| dobey | ToyKeeper: so what happened is that you previously purchased the vowels, but for some reason the client wasn't able to acknowledge, and for some reason it still can't, so every time you cancel the purchase, and we ask the server if the item is purchased, it says it is, because it's been purchased, just not acknowledged yet | 23:16 |
| ToyKeeper | dobey: I should have logs after this fresh install. | 23:17 |
| dobey | ToyKeeper: great. seeing those logs should be able to help a bit. might have to ping the ols people to poke the server though | 23:17 |
| Saviq | plars, oh hmm, but it's able to flash https://unity8-jenkins.ubuntu.com/job/device-0-flash/node=krillin-07,release=vivid+overlay/5/console - any chance recover doesn't use the custom --recovery-image with adb? | 23:18 |
| plars | Saviq: easiest thing to do would be to run the recover tool from lp:lifeboat at the beginning of your job (as we talked about earlier, hopefully you are doing that already because it will make this really easy), and adjust your script to add --developer-mode and restart the job | 23:21 |
| Saviq | plars, yeah, that's what I'm doing, but recover didn't complete https://unity8-jenkins.ubuntu.com/job/run-commands/582/console | 23:24 |
| Saviq | "error: closed" suggests .adb_onlock isn't there | 23:25 |
| * Saviq tries to bootstrap again | 23:26 | |
| Saviq | since adb reboot bootloader works even if adb is closed | 23:27 |
| Saviq | ok that worked | 23:35 |
| plars | Saviq: sorry, I was afk trying to sorry out supper for the kids. Did it work now? | 23:37 |
| plars | Saviq: recover *should* work no matter what, since it resets the device to fastboot and does a full reinstall | 23:38 |
| Saviq | plars, well, yeah, but it doesn't, it bails out with "error: closed", which AFAIK means .adb_onlock isn't there | 23:39 |
| Saviq | which I don't get, since I bootstrapped with --developer-mode and all | 23:39 |
| Saviq | I'll probably be able to recover manually, but will it survive another bootstrap :/ | 23:43 |
| dobey | ToyKeeper: i have to go get dinner and stuff now. if you can e-mail those logs to me, i'll try to look at them as soon as i can, and hopefully we can get the issue resolved and move forward. | 23:43 |
| plars | Saviq: so recovery is getting it to a state where you can adb to it, but when you reinstall it, you can't reach it again? | 23:52 |
| ToyKeeper | dobey: Sent. | 23:52 |
| Saviq | plars, no, recover is getting it to a state where adb goes "error: closed" | 23:53 |
| Saviq | plars, which is basically .adb_onlock not being there | 23:53 |
| Saviq | plars, I've put the file there manually via recovery, no idea why it would not be there after bootstrap with --developer-mode (or how can that file survive bootstrap if u-d-f doesn't put it there ¿?) | 23:54 |
| plars | Saviq: I would be happy to take a look if you like, just let me know when you aren't doing something on it. I don't want to stomp on what you are doing | 23:54 |
| Saviq | plars, for now I have things working, I will let you know what I find out | 23:55 |
| plars | Saviq: ok, sounds good | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!