[03:45] <bzoltan> robru:  I have just top approved the UITK MRs  in the silo38, would you push the publish button?
[03:46] <robru> bzoltan: you can now ;-)
[03:46] <bzoltan> robru: wow! Really? Fantastic :)
[03:47] <robru> bzoltan: yes, as long as there's no packaging changes. You might need a core dev.
[03:48] <bzoltan> robru:  I see... I actually have packaging changes
[03:49] <robru> bzoltan: then you need a core dev to pull the trigger, i no longer have any special power here
[03:49] <bzoltan> robru: You do :) knowledge is power
[03:49] <bzoltan> robru: But I try to catch a core dev...
[03:49] <robru> bzoltan: :-P
[03:50] <robru> bzoltan: my go to guys are eod, not sure who's around now
[03:50] <bzoltan> robru: I will wait for somebody in the UK timezone
[03:54] <robru> bzoltan: you should try hitting publish anyway, it'll generate the diffs and can paste the URL to the core dev
[04:31] <elopio> Saviq: I think there is none.
[04:33] <Mirv> morning
[04:33] <robru> Mirv: hola
[04:34] <Mirv> hola!
[04:42] <robru> Mirv: made some small fixes to the train here and there, nothing huge, but some new checks on the publish job. I'll stick around for a bit to make sure nothing explodes
[04:43] <robru> Mirv: please publish something if you can ;-)
[04:45] <Mirv> ok, let's see...
[04:51] <robru> well that seems to be in order
[04:51] <robru> Mirv: the new checks are at the very beginning so those two errors indicate that nothing tripped inappropriately
[04:54] <Mirv> ok
[05:08] <robru> Mirv: the new checks are that publish job will abort if the request is in a failed state (either build failure or qa failure) and also if there are dirty packages. Somehow there never was a check to prevent publishing duty silos until now.
[05:08] <robru> Mirv: publish checks are a lot more important now that anybody can do it.
[05:08] <robru> So I'm feeling good about that
[05:10] <Mirv> robru: the diff:s here https://ci-train.ubuntu.com/job/ubuntu-landing-044-2-publish/18/ are a bit fun, having a lot more that is the actual diff to the overlay silo. probably because earlier those have been dual landed and now it's vivid only landing.
[05:11] <Mirv> only the last versions in the changelogs are really new
[05:12] <robru> Mirv: that's because the request is not targeted at the overlay so you're diffing to vivid archive
[05:13] <Mirv> robru: ha, good point!
[05:13] <robru> Mirv: note there's a 6 month gap in the versions being diffed.
[05:14] <Mirv> trying again
[05:14] <Mirv> robru: thanks!
[05:16] <robru> Mirv: i also fixed a bad bug in diffing dual silos, it used to diff the local vivid build against the wily archive version. Wasn't a huge problem before because the vivid version was always just a copy, but we have new magic now that allows people to munge their packaging, so the diffs got worse there, fixed that up good
[05:20] <Mirv> robru: weird, now the correct delta was generated for u-d-m but the others show still the half a year https://ci-train.ubuntu.com/job/ubuntu-landing-044-2-publish/20/
[05:21] <robru> Hmmmmmmm
[05:21] <Mirv> according to the log it'd look like it's doing the correct thing
[05:21] <Mirv> robru: ah, it's probably because those three don't _have_ packaging changes when diff:d correctly
[05:22] <robru> Mirv: do they not exist in the overlay?
[05:22] <robru> Mirv: don't publish yet i want to poke at this a bit
[05:23] <Mirv> robru: ok. yes, they do exist but maybe the zero sized packaging diff:s are being thrown away (since there were no changes) and the old diff:s from two jobs earlier are kept visible
[05:25] <robru> Mirv: that doesn't sound likely to me. I have a theory though, lemme check
[05:26] <robru> Mirv: no this is really weird. the previous diff is cleared...
[05:29] <robru> Mirv: literally the first thing it does is delete the old diffs: https://ci-train.ubuntu.com/job/ubuntu-landing-044-2-publish/21/console
[05:29] <robru> and the debug log shows it's downloading the correct version
[05:31] <Mirv> robru: interesting
[05:32] <robru> Mirv: this is really bizarre, it is absolutely deleting the old diffs and the old source packages that it's diffing against and making a new diff every time
[05:32] <robru> Mirv: unfortnately the debug log doesn't show the exact debdiff command
[05:32] <Mirv> robru: so the _packaging_changes.diff is not somehow extracted from the full diff, but if and only if there are packaging changes? the full diff:s are correct.
[05:33] <robru> oh god let me dig out the code
[05:36] <robru> Mirv: nah man it makes the packaging diff by filtering down the content diff: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/cupstream2distro/packagemanager.py#L250
[05:38] <robru> Mirv: I'm thinking like maybe it's generating the diff twice, first it makes a wrong contents & wrong packaging changes, then makes a correct content diff but then doesn't touch the packaging, so the old wrong one comes through
[05:39] <robru> but I don't really see how that would happen, the debug log doesn't show it...
[05:40] <robru> Mirv: wait I think I've got it
[05:40] <robru> Mirv: it deletes the diffs from the workspace (where artifacts live) but not from the silo dir
[05:41] <robru> Mirv: ok https://ci-train.ubuntu.com/job/ubuntu-landing-044-2-publish/22/
[05:43] <Mirv> robru: ok! another corner case found. thanks again!
[05:43] <robru> Mirv: you're welcome.
[05:44] <robru> I'll push a quick fix, if it happens again, you need to use cyphermox-test job to delete ~/silos/ubuntu/landng-NNN/*.diff
=== evanwang is now known as evanwang_afk
=== evanwang_afk is now known as evanwang
[06:16] <bzoltan> Mirv:  seb128 was kind and ack the silo38. How can I publish now? I try the publish link, but it fails and says that the silo has bad status... I guess it means the failed wily builds, what we do not care for now :)
[06:24] <Saviq> elopio, ended up with platform.linux_distribution, seems to work fine
[06:25] <Saviq> cihelp, can someone please have a look at boottest for qtmir-gles and unity8?
[06:26] <Saviq> also, is armhf in a huge queue? it's been over 8h now that autopkgtest for unity8 migration is "Test in progress"
[06:27] <seb128> Saviq, cf #ubuntu-desktop, but basically yes, kubuntu people uploaded a stack of kde packages that created quite some backlog
[06:29] <Mirv> bzoltan: the publishing needs to be done by that core dev directly
[06:30] <Mirv> bzoltan: but yes let's fix the status first, just some moments
[06:48] <robru> bah, 'merge conflict' status is a misnomer
[06:49] <Mirv> bzoltan: running watch-only build
[06:50] <Mirv> robru: after changing a silo to vivid only from dual, it still seems to fetch wily data https://ci-train.ubuntu.com/job/ubuntu-landing-038-1-build/91/console
[06:51] <robru> Mirv: yes, watching watches the PPA. if you don't want the wily package you need to delete it
[06:51] <Mirv> robru: it was already deleted
[06:52] <Mirv> maybe there's a delay to be waited after that
[06:52] <Mirv> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-038/+packages
[06:52] <robru> Mirv: deleting does take a minute.
[06:52] <robru> Mirv: it iterates on the PPA, dunno what to tell you, try it again
[06:52] <Mirv> ok, waiting the 5-15 mins
[07:00] <robru> Mirv: ugh just found a bug in merge&clean
[07:01] <robru> Mirv: these packages that are munging the packaging in order to dual building in spite of ABI breaks have uncommitted changes that screw things up.
[07:01] <robru> I guess the fix is to just throw in a 'bzr revert' after the builds are uploaded
[07:06] <Mirv> robru: ok :(
[07:07] <robru> Mirv: sigh, everything is exploding
[07:15] <Mirv> robru: interesting that the 038 still keeps on staring at deleted wily logs while 25 minutes have gone since deletion https://ci-train.ubuntu.com/job/ubuntu-landing-038-1-build/96/console
[07:18] <robru> uh
[07:22] <robru> Mirv: oh it is picking it up from the local silo files
[07:23] <robru> Mirv: this is really not a supported use case I should mention ;-)
[07:23] <Saviq> cihelp, can someone please re-kick boottests for unity8 and qtmir-gles?
[07:23] <robru> Mirv: I guess I'll manually delete the files from the silo
[07:26] <robru> Mirv: it seems the thing is that in a dual silo, the wily build happens in a directory called "ubuntu-ui-toolkit" but the vivid build happens in "ubuntu-ui-toolkit_+vivid", but when you switch it to just vivid, it expects the vivid build in the "ubuntu-ui-toolkit" dir
[07:26] <robru> Mirv: what what are we trying to do? just publish only the vivid packages to the overlay?
[07:29] <robru> Mirv: I'm thinking instead you should set it back for dual, manually copy the packages from silo ppa to overlay ppa, then manually merge without publishing
[07:32] <Mirv> robru: right... publish just vivid to overlay, since wily has currently a GCC problem
[07:33] <Mirv> robru: while publishing the next release again to wily or wily+1 + vivid, ie dual
[07:33] <Mirv> robru: yeah, I was thinking about that approach, and I can do that indeed
[07:33] <robru> Mirv: go ahead with that for now, I'm writing an email to discuss the issue
[07:43] <Mirv> bzoltan: robru: ok 038 (manual) publish + merge & clean done
[07:43] <Mirv> to overlay only
[07:43] <robru> Mirv: thanks
[07:44] <robru> Mirv: I pushed a fix for that bzr revert thing so all future builds should be ok, I just gotta analyze current silos to make sure there's no other surprises lurking
[07:45] <Mirv> ok!
=== tsdgeos_ is now known as tsdgeos
=== chihchun_afk is now known as chihchun
[07:59] <robru> Mirv: ok existing silos seem clean. there are a surprising number of bzr branches with uncommitted changes but it seems to be all builds that failed partway through that landers need to fix themselves, nothing to do with the new packaging black magic
[08:14] <psivaa> Saviq: unity8 and qtmir-gles boottests haven't been passing for a while now, but i've restarted both of them
[08:15] <Mirv> robru: alright, good to know
[08:16] <robru> blast, 2AM and I'm overcome with hunger. can't sleep hungry, but if I eat it'll keep me up.. lose/lose
[08:19] <Mirv> :(
[08:23] <robru> I'll try just having a drink, maybe that'll trick my hunger into going away long enough to sleep...
[08:23] <robru> goodnight!
[08:23] <bzoltan> robru: good night mate, have a good rest :)
[08:24] <robru> thanks
[08:36] <Saviq> psivaa, I'm not sure I understand what the status of the boottests is, then - they fail, you restart and they pass (so flaky/unreliable) or downright broken? can we do anything about that?
[08:38] <psivaa> Saviq: they do haven't passed in the recent past, even on retries ( i just wanted to confirm this is the case with this new uploads by retrying)
[08:39] <psivaa> Saviq: unity8 fails because of 'ERROR: timed out waiting for Unity greeter'
[08:39] <jibel> psivaa, why do they fail in this case?
[08:40] <popey> sil2100: was the ubuntu-pd image fixed yesterday do you know? (I don't see a new image spun out)
[08:42] <sil2100> popey: no...
[08:42] <sil2100> popey: not sure if we had any definite fixes, I think bregma wanted to try something out but I didn't see him say how it went
[08:44] <popey> ok
[08:50] <popey> sil2100: you may be interested to know we broke backwards compatibility in mir in the rc-proposed images
[08:50] <popey> sil2100: app developers had to re-build their apps
[08:50] <popey> sil2100: https://github.com/pseuudonym404/neverball-touch/issues/11
[08:51] <popey> well, broke between 15.04 and rc-proposed anyway :)
[08:51] <popey> so we may get more of these happen when the next ota goes out
[08:52] <Saviq> psivaa, are there steps we could take to reproduce this locally? FWIW we just got autopilot runs working yesterday on wily, so there's nothing inherently broken there
[08:54] <psivaa> Saviq: Let me try something before asking you to reproduce
[08:54] <sil2100> popey: do you remember in which image the breakage happened?
[08:55] <sil2100> We will add a new framework anyway
=== sil2100 changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? ping cihelp | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: wily final freeze is now in effect
[10:01] <psivaa> Saviq: my attemptp 'fix' those tests failed.
[10:02] <psivaa> Basically with the latest image (204) provisioning krillin fails so we have had to use image 191
[10:02] <sil2100> ogra_: hey, could you take a look at https://code.launchpad.net/~sil2100/livecd-rootfs/remove_apt_lists/+merge/271951 in some free cycles of your time? :)
[10:02] <sil2100> ogra_: not sure if that's the correct way, first time I use hooks
[10:03] <psivaa> but with 191, unity8 has dependency issues that it throws errors like, timing out waiting for unity greeter etc
[10:06] <ogra_> sil2100, important is that you make the hook executable ... looks fine to me
[10:25] <Saviq> are migrations frozen due to beta?
[10:26] <bregma> popey, sil2100, no luck yet with hacking on the -pd image so no solution yet
[10:26] <sil2100> bregma: :<
[10:26] <sil2100> ogra_: \o/
[10:27] <popey> bregma: ok :)
[10:27] <bregma> tried resettin the link in /etc, no difference
[10:33] <Saviq> psivaa, is there somewhere a description of how we could reproduce the boottest as it's ran for migration? I'd like to see if this is a real problem and resolve if possible
[10:35] <anpok_> Saviq: http://bazaar.launchpad.net/~canonical-ci-engineering/ubuntu-touch-boottest/trunk/view/head:/boottest.sh
[10:35] <anpok_> it basically just installs the new package without upgrading the other packages found in the silo
[10:35] <Saviq> anpok_, thanks
[10:36] <anpok_> which is a problem for our drivers.. since those are only pulled in through a separate meta package..
[10:36] <anpok_> but it is good at detecting abi breaks..
[10:37] <ogra_> sil2100, btw, did you notice that your i386 image failed tonight ?
[10:38] <psivaa> Saviq: yea, what anpok_ said above. There is no specific instructions on a wiki like place, which I think we can fix
[10:39] <sil2100> ogra_: yeah, saw an e-mail but didn't read the logs yet, my machine is hogged by translations now ;)
[10:50] <psivaa> Saviq: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html doesn't appear to be waiting either of unity8 or qtmir-gles boottest results
[10:50] <Saviq> psivaa, yeah, I think it's beta freeze time
[10:53] <Saviq> unity8 migrated, but qtmir{,-gles} just missed it
[11:13] <cjwatson> Saviq: I don't think it's a beta freeze issue
[11:15] <cjwatson> Saviq: qtmir-gles is at version 0.4.6+15.10.20150918-0ubuntu when it should be at version 0.4.6+15.10.20150918-0ubuntu1, and this breaks stuff excitingly
[11:15] <cjwatson> proposed-migration is picking up on that, albeit not very clearly
[11:15] <Saviq> cjwatson, oh? robru, sil2100 ↑
[11:16] <Saviq> looks like the train managed to mismangle the version number then?
[11:16] <Saviq> or actually
[11:16] <Saviq> my fault :/
[11:17] <Saviq> somehow I managed to strip the 1 when building qtmir-gles
[11:28] <sil2100> uuh
[11:28] <sil2100> I guess we'll need to re-release it woth the version proper
[11:28] <sil2100> Let me help with that
[11:29] <sil2100> Saviq, cjwatson: on it
[11:30] <Saviq> sil2100, it's already rebuilding in the silo
[11:30] <Saviq> sil2100, IIUC it will just need a publish when done
[11:30] <sil2100> Saviq: oh, ok then, I wanted to do that manually
[11:30] <sil2100> Saviq: yeah
[11:36] <Saviq> sil2100, can you publish please? /me not authorized
[11:37] <sil2100> On it
=== chihchun is now known as chihchun_afk
[11:59] <bfiller> Mirv: which MR in silo 46 has the non-build commit?
[12:00] <Saviq> fginther, hey, I saw a job yesterday that got stuck in rebooting the device, so it seems unreliable
[12:00] <Saviq> fginther, http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-wily-mako/423/console
[12:01] <Mirv> bfiller: https://code.launchpad.net/~artmello/gallery-app/gallery-app-avoid_reload_fullscreen_toggle/+merge/269424
[12:02] <Mirv> the PPA build was done 5 days before the commit 1240
[12:04] <bfiller> Mirv: ah right, I updated the click package (which was tested by QA) but never rebuilt the silo (debs don't get tested anyway)
=== alan_g is now known as alan_g|lunch
[12:04] <bfiller> Mirv: let me rebuild the silo, but don't think we need additional QA as we only test the click and that is correct
[12:04] <Mirv> bfiller: makes sense
[12:04] <Mirv> bfiller: good that the click was up-to-date
[12:05] <bfiller> Mirv: just double checking
[12:08] <bfiller> Mirv: confirmed, click has that change
=== pat_ is now known as Guest88770
[12:42] <Saviq> psivaa, http://paste.ubuntu.com/12530565/ not sure how's that... the device is provisioned in writable mode and I can create that file, it's as if adt does something special
[12:52] <psivaa> Saviq: let me take a look
[12:56] <psivaa> Saviq: Curious which image you provisioned the device with
=== alan_g|lunch is now known as alan_g
[12:59] <psivaa> Saviq: also, not really saying it could be related but if you did have the right wifi.conf
[13:00] <Saviq> psivaa, devel-proposed, and yeah wifi's fine
[13:10] <psivaa> Saviq: looking at the serial number of the device you tested with, it doesn't look like krillin?
[13:10] <Saviq> psivaa, that's mako
[13:11] <psivaa> Saviq: boottest is supposed to be run on krillin
[13:11] <psivaa> http://bazaar.launchpad.net/~canonical-ci-engineering/ubuntu-touch-boottest/trunk/view/head:/boottest.sh#L112
[13:11] <psivaa> Not sure if you adapted this line accordingly
[13:12] <Saviq> psivaa, there's mako images in those channels too afaict, will confirm
[14:02] <pstolowski> Mirv, hey, re your earlier question about qnetwork bug - dobey confirmed my memory of about "QIODevice::Write: device not open" error in Apps/Store scope logs. these scopes make a few http requests in a row in some cases and same qnetworkaccessmanager instance is reused for consecutive dash searches. so it may potentially be a victim of that bug, though idea how to trigger that. if we decide to land this fix, we need to excercise Apps/Store obvio
[14:02] <pstolowski> usly
[14:02] <pstolowski> s/idea/no idea/
[14:05] <dobey> pstolowski: now that there are qt bindings for the scopes API in the phone, there might be more and more scopes using it in the future too
[14:07] <Saviq> psivaa, can you please skip the boottest for qtmir-gles since we know it's not reliable
[14:10] <morphis> Mirv, sil2100: any idea what I do wrong with https://ci-train.ubuntu.com/job/ubuntu-landing-025-1-build/103/console which is for https://requests.ci-train.ubuntu.com/#/ticket/408 ?
[14:11] <rvr> sil2100: Sending email to ubuntu-translators for string freeze
[14:12] <sil2100> rvr: ok, thanks!
[14:12] <rvr> sil2100: Just to confirm no changes,  https://translations.launchpad.net/ubuntu-rtm/15.04/ is the place to watch them right?
[14:12] <sil2100> morphis: let me take a look
[14:12] <sil2100> rvr: yeah :)
[14:12] <rvr> Nice
[14:12] <morphis> sil2100: thanks
[14:13] <psivaa> Saviq: will do that. in a meeting. once that's over, i'll do that
[14:13] <Saviq> kthx
[14:15] <sil2100> morphis: from what I see so far it looks like bad luck!
[14:15] <sil2100> morphis: hah, yeah...
[14:16] <sil2100> morphis: so, you'll need to get this silo re-assigned
[14:17] <pstolowski> dobey, yes, but no scopes use qt bindings atm, they are in experimental namespace btw
[14:18] <morphis> sil2100: which then doesn't work currently with the assign job ..
[14:18] <morphis> see https://ci-train.ubuntu.com/job/prepare-silo/6234/console
[14:19] <sil2100> morphis: you need to first abandon the silo and then re-assign
[14:19] <sil2100> morphis: since you need a different silo
[14:20] <sil2100> morphis: the reason this happens is that someone, half a year ago, in this silo, uploaded a higher version number of the vivid package to this PPA
[14:20] <sil2100> morphis: and LP PPAs have a good memory
[14:20] <morphis> I see
[14:21] <seb128> sil2100, so, the unity8 fix for libusermetrics landing, can you revert your revert?
[14:21] <seb128> landed
[14:21] <sil2100> seb128: excellent, sure thing
[14:21] <seb128> thanks
[14:28] <morphis> sil2100: thanks a lot! works now
[14:36] <psivaa> Saviq: qtmir-gles has been skipped by a synthetic pass
[14:36] <psivaa> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[14:49] <boiko> sil2100: when I add a new MR to a silo, do I still need to click "Assing" or can I just rebuild it?
[14:50] <sil2100> boiko: you can just rebuild it
[14:50] <sil2100> Reconfigures are no longer required :)
[14:50] <boiko> sil2100: great! thanks
[14:50] <popey> sil2100: where can i see the version numbers that should be on each retail device?
[14:50] <popey> e.g. what I see in "About this phone"
[14:51] <ogra_> popey, most likely somewhere in the output of "getprop"
[14:51] <popey> no, i mean, on the wiki
[14:51] <popey> or somewhere else, documented
[14:52] <ogra_> getprop ro.serialno
[14:52] <ogra_> popey, ah, no idea :)
[14:52] <sil2100> popey: you mean, the version numbers of each OTA for each device?
[14:52] <popey> aha! https://wiki.ubuntu.com/Touch/ReleaseNotes/OTA-6
[14:53] <popey> I have seen a few people say they never got OTA-6 on E5
[14:53] <popey> and some people (not the same ones) saying GPS broken on E5
[14:53] <sil2100> hmm
=== chihchun_afk is now known as chihchun
[15:23] <pmcgowan> popey, sil2100 there is a decoder ring at the bottom of my ota features doc
[15:26] <bfiller> popey: when you get a chance if you don't mind reviewing/publishing new gallery app in the store
=== chihchun is now known as chihchun_afk
[15:40] <psivaa> Saviq: how goes reproducing unity8 boottest failures locally?
[15:49] <popey> bfiller: sure
[15:49] <popey> pmcgowan: which doc is that? :S
[15:51] <popey> bfiller: done
[15:51] <Saviq> psivaa, was otp, trying again now, FWIW the channels listed in boottest both have mako images too
[15:51] <bfiller> popey: thanks
[15:52] <popey> np
[15:57] <fginther> Saviq, Yes, I see it. looks like 1 out of 9 runs have hit that problem
[16:15] <Saviq> psivaa, now it failed for me with "comm: file 2 is not in sorted order"
[16:16] <Saviq> psivaa, also, I'm not sure I get what NODE_NAME is for... it says that if I have a phone available locally, I should export ANDROID_SERIAL and NODE_NAME=yes
[16:16] <Saviq> but that means it won't provision the device, is that on purpose, or should I unset NODE_NAME?
[16:18] <Saviq> psivaa, | sort | uniq seems to be missing from the dpkg-query line
[16:19] <psivaa> Saviq: I've seen this sorting issue when I run them manually,  but on our jenkins runs this hasn't been an issue
[16:19] <Saviq> at least it seems to continue with that
[16:21] <psivaa> Saviq: file 2 is installed.packages and that's the output of dpkg-query and that normally is sorted, no?
[16:21] <pmcgowan> sil2100, did we not do a build last night? I am surprised not to get stuff that landed early yesterday
[16:21] <Saviq> psivaa, dunno, apparently not ;)
[16:22] <Saviq> psivaa, I think I know what the issue might be, same as I mentioned to fginther, reboot is unreliable in wily (gets stuck before rebooting)
[16:22] <psivaa> Saviq: Not sure about that, adb shell usually works
[16:22] <Saviq> hmm ok then not this
[16:23] <Saviq> psivaa, ok so apart from having to reboot via power button, the test passed for me locally on mako
[16:24] <Saviq> let me collect some info
[16:25] <psivaa> Saviq: ok, as long as the device booted, we should consider it a 'PASS' although the intended device is krillin
[16:26] <Saviq> psivaa, sure, will try krillin in a mo, need to back it up as it's my daily driver
[16:26] <psivaa> Saviq: ack, thank you
[16:27] <Saviq> psivaa, this is what I did http://pastebin.ubuntu.com/12532466/
[16:28] <Saviq> psivaa, if I wanted boottest.sh to provision the device, I should leave NODE_NAME unset?
[16:30] <psivaa> Saviq: i think according to http://bazaar.launchpad.net/~canonical-ci-engineering/ubuntu-touch-boottest/trunk/view/head:/boottest.sh#L79 you'd need to set to 'yes'
[16:30] <psivaa> fginther: ^ would you mind confirming please?
[16:30] <fginther> psivaa, looking
[16:32] <Saviq> psivaa, yeah, that skips provisioning for me
[16:32] <fginther> psivaa, Saviq, that's what it looks like to me too. Set ANDROID_SERIAL=your_device_id and NODE_NAME=yes
[16:32] <Saviq> although [ -n "$NODE_NAME" ] suggests otherwise...
[16:33] <Saviq> ok will verify again
[16:33] <oSoMoN> ubuntu-qa: isn’t vrruiz around? communicating with him through trello card comments is a bit of a pain…
[16:33] <rvr> oSoMoN: Yes
[16:33] <rvr> oSoMoN: I'm here :P
[16:33] <davmor2> oSoMoN: rvr is vrruiz
[16:33] <oSoMoN> rvr, your IRC nickname in the directory is out of date!
[16:34] <davmor2> oSoMoN: he just likes to confuse people
[16:34] <rvr> oSoMoN: I'm vrruiz @irc.canonical.com
[16:34] <rvr> rvr here :P
[16:34] <Saviq> just to make it easier ;)
[16:34] <oSoMoN> rvr, nasty!
[16:34] <rvr> oSoMoN: So, now I'm not sure it only happens with silo 35
[16:35] <oSoMoN> rvr, I’m seeing the error with the youtube video if I browse to the URL you pasted, but if I then search for "let’s talk about reagan for a second" in the youtube search, tap on that same video in the search results, it plays just fine
[16:35] <rvr> oSoMoN: davmor2 was telling me that he found a similar problem
[16:35] <oSoMoN> rvr, and I highly doubt it’s specific to that silo, there’s nothing in there related to video playback or even UA string overrides (which could possibly explain what you’re seeing)
[16:36] <rvr> oSoMoN: davmor2 says «that is a youtube issue, long press on the video and open in another tab you get the HQ blue button and it will play,  I think the url gets confused between mobile and desktop views»
[16:36] <rvr> I was about to check
[16:36] <oSoMoN> rvr, right, that’s what happens when I search the video I guess
[16:37] <rvr> davmor2: Indeed
[16:37] <rvr> davmor2: HD version plays nicely
[16:38] <davmor2> rvr: it's happens on and off with videos across the board sing the release of ota 6 hence assuming it was a youtube issue rather than ours
[16:38] <davmor2> s/happens/happened
[16:38] <davmor2> s/sing/since
[16:41] <rvr> davmor2: Ok
[16:42] <rvr> Weird, it worked without the silo, not with it
=== alan_g is now known as alan_g|EOD
[16:42] <oSoMoN> rvr, just tested on my krillin running plain rc-proposed (without the silo), and I’m seeing the issue too, so definitely not a regression introduced by silo 35
[16:43] <davmor2> rvr: yes because different calls,  I get it now I look one day I have to open it in a new tab, I open it again the next day to show my wife and it opens no issues
[16:44] <oSoMoN> rvr, davmor2: stop watching youtube videos at work!
[16:44] <rvr> oSoMoN: lol
[16:44] <rvr> oSoMoN: Ok, just reproduced without the silo
[16:45] <rvr> oSoMoN: Everything else looked fine, so approving it
[16:45] <davmor2> oSoMoN: only way to test the scope interaction with the browser :P
[16:45] <oSoMoN> rvr, thanks!
[16:46] <Saviq> psivaa, ah, NODE_NAME is $3, not env
[16:47] <Saviq> psivaa, but then 'recover.py yes' bails out...
[16:50] <Saviq> ok so no, locally I need to provision myself, NODE_NAME=yes does not work, because "yes" is not a defined device
[16:50] <Saviq> psivaa, fginther FYI ↑
[16:51] <psivaa> Saviq: yea, let me take a look at recovery.py
[16:53] <davmor2> oSoMoN: could the url hiccup be due to the convergence trigger desktop over mobile and then switching back when it realises at all?  Just pure supposition and quess work on my part
[16:54] <oSoMoN> davmor2, there’s no such clever logic in place (yet)
[16:54] <oSoMoN> trainguards: it seems publication of silo 35 failed, can someone please advise? https://ci-train.ubuntu.com/job/ubuntu-landing-035-2-publish/27/console
[17:02] <psivaa> Saviq: it is an ugly hack but I dont think you'd need to run recover.py when run locally. Could you try with commented out recover.py calls
[17:02] <psivaa> Sorry I dont have a device handy to try it myself
[17:03] <Saviq> psivaa, I'm just provisioning myself, atm network-manager went apeshit
[17:03] <psivaa> Saviq: right, that's why we used an older image r191
[17:04] <Saviq> that's over 100 images back...
[17:04] <Saviq> I can imagine all kinds of things going wrong this way
[17:05] <Saviq> trying anyway
[17:05] <robru> oSoMoN: just run it again. That error is a launchpad connectivity error, should be transient and fix itself
[17:05] <Saviq> psivaa, is there a bug for NM broken on wily/krillin?
[17:05] <psivaa> Saviq: no, r204 is the latest
[17:05] <psivaa> so we're not too old
[17:05] <Saviq> Flashing version 330 from ubuntu-touch/devel-proposed
[17:05] <Saviq> psivaa, ↑
[17:06] <Saviq> that's latest krillin devel-proposed
[17:06] <psivaa> Saviq: we must be looking at different places? https://system-image.ubuntu.com/ubuntu-touch/devel-proposed/krillin.en/krillin/index.json
[17:06] <oSoMoN> robru, ok, thanks
[17:06] <Saviq> psivaa, oh well, yeah, let me use /krillin.en then
[17:59] <robru> dbarth_: you have 6 silos assigned, including some that are quite old, can you review these and potentially abandon a couple? https://requests.ci-train.ubuntu.com/#/user/dbarth
[18:00] <robru> boiko: also you have 5 assignd, please free some if possible: https://requests.ci-train.ubuntu.com/#/user/boiko
[18:01] <Saviq> psivaa, ok, I got krillin to fail, it must be because of some dependencies that didn't get updated
[18:01] <boiko> robru: yeah, trying to test and land those
[18:02] <robru> boiko: some of them are quite old, eg are you sure https://requests.ci-train.ubuntu.com/#/ticket/37 is still relevant?
[18:02] <boiko> robru: actually only 4 are mine, one is bfiller's and renato's, I just added my name there to help while bfiller was on holiday
[18:03] <Saviq> psivaa, so the problem is that you held the image back (to fight with the broken NM - is there a bug for it?), and we've not updated our deps when apparently we should have
[18:06] <boiko> robru: I think I can free that one for
[18:06] <boiko> robru: for now
[18:07] <robru> boiko: wait
[18:07] <boiko> robru: we are not actively testing it, already abandoned it
[18:07] <robru> boiko: I don't want to step on work you're actually doing, it just looks forgotten-about to me
[18:07] <robru> boiko: leave it if youre actually using it
[18:07] <robru> boiko: oh ok, thanks
[18:07] <boiko> robru: that's fine, we won't be testing it for a few days
[18:17] <jibel> Saviq, bug 1496434
[18:17] <ubot5> bug 1496434 in network-manager (Ubuntu) "network-manager crash on boot on krillin/devel-proposed" [High,Confirmed] https://launchpad.net/bugs/1496434
[18:17] <Saviq> jibel, thanks
[18:17] <jibel> Saviq, then you'll see bug 1496460
[18:17] <ubot5> bug 1496460 in ubuntu-push (Ubuntu) "krillin/devel-proposed - ubuntu-push-client uses an excessive amount of memory" [Undecided,New] https://launchpad.net/bugs/1496460
[18:18] <jibel> which is likely a consequence of nm crash
[18:25] <pmcgowan> oh my nasty
[18:26] <pmcgowan> oh those are wily eh
[18:31] <Saviq> yeah, someone has to care ;)
[18:38] <bfiller> boiko: isnt' silo 20 the one we need for messaging-framework, or has that moved elsewhere?
[18:40] <boiko> bfiller: that was the one, but we can upload all the required packages to the ppa for now (tiago and I won't have time to review that in the next couple of days at least)
[18:40] <boiko> bfiller: I saved the list of MRs too, in case we need to recreate the silo
[18:41] <bfiller> boiko: ok, yes keep the list as we'll definitely need to get back to this after we finish current tasks
[18:42] <boiko> bfiller: yep
[19:03] <psivaa> Saviq: I think that is the summary of the problem. Not sure if we have any bug for the NM issue
[19:03] <psivaa> let me find out
[19:11] <jibel> psivaa, I pasted the bug # earlier
[19:12] <jibel> psivaa, , bug 1496434
[19:12] <ubot5> bug 1496434 in network-manager (Ubuntu) "network-manager crash on boot on krillin/devel-proposed" [High,Confirmed] https://launchpad.net/bugs/1496434
[19:12] <psivaa> jibel: thanks for that.
[19:12] <psivaa> Saviq: ^
[19:13] <Saviq> psivaa, yup, saw that, I'm building unity8 and qtmir with proper deps in silo 38, will test whether it helps soon
[19:13] <psivaa> Saviq: ack, thx
[19:22] <jibel> psivaa, which image did you say you flash for boottests?
[19:22] <jibel> psivaa, 200-ish?
[19:22] <psivaa> jibel: 191
[19:22] <jibel> psivaa, on krillin.en?
[19:23] <psivaa> jibel: yes
[19:23] <jibel> psivaa, thanks
[19:23] <psivaa> jibel: we tried with 202, i think and it failed. and i know 204 failed today
[19:38] <jibel> psivaa, yeah devel-proposed has more important problems to fix than checking if it boots :)
[22:35] <robru> kenvandine: got a sec for an ack? https://ci-train.ubuntu.com/job/ubuntu-landing-057-2-publish/5/ plskthx