[00:11] <robru> cyphermox, can you do a packaging review for mir? http://162.213.34.102/job/landing-019-2-publish/
[00:11] <cyphermox> ok
[00:11] <robru> thanks
[00:13] <robru> cyphermox, seems mostly fine, but there was some stuff that i wasn't sure about
[00:17] <cyphermox> that override for dh_install looks wrong
[00:17] <cyphermox>  override_dh_install:
[00:17] <cyphermox> -	dh_install --fail-missing
[00:17] <cyphermox> +	dh_install --fail-missing \
[00:17] <cyphermox> +	  -Xusr/lib/$(DEB_HOST_MULTIARCH)/libmirplatformgraphics.so \
[00:17] <cyphermox> +	  -Xusr/lib/$(DEB_HOST_MULTIARCH)/libmirclientplatform.so
[00:17] <cyphermox> the files are created in the CMakeLists as a symlink, it probably shouldn't be excluded.
[00:17] <robru> cyphermox, yeah, that confused me a bit.
[00:17] <cyphermox> I haven't dug more deeply
[00:17] <robru> kgunn, can you explain this? ^^
[00:18] <robru> cyphermox, I mean, I installed and ran it myself, it's all *working*...
[00:19] <cyphermox> what landing is this?
[00:19] <robru> cyphermox, silo 19
[00:19] <robru> cyphermox, row 51
[00:19] <cyphermox> good
[00:20] <robru> ?
[00:23] <kgunn> robru: oh, that's because there are different platforms....one for mesa (desktop) and one for android (mobile)
[00:24] <kgunn> at least that's my educated guess
[00:24] <robru> cyphermox, what do you think? can we accept that? i don't really understand the issue
[00:25] <cyphermox> just a second I'm checking
[00:25] <cyphermox> I think it's fine, but I want to make sure
[00:27] <cyphermox> kgunn: that's not really the issue though, it's that these files are getting explicitly ignored from the install. are the symlinks just there for tests?
[00:28] <cyphermox> wait no that wouldn't make any sense, the symlink would just get overwritten
[00:29] <robru> kgunn, it is a bit odd that you're creating the symlinks in cmake and then ignoring them from debian/rules. better would be to just not create them in the first place.
[00:29] <robru> cyphermox, but I don't think we should block on that, do you? maybe just submit a quick branch for the next landing
[00:30] <cyphermox> it's relevant if it breaks upgrade from one mir to the next on desktop
[00:31] <cyphermox> kgunn: so the issue I have is that there is a symlink made from each platform to the file in /usr/lib/$triplet, and it's not being installed in the packages
[00:37] <veebers> robru, cyphermox: Would you know which project to use to file a bug for ci-train? I seem to recall that it's perhaps cupstream2distro or something similar
[00:37] <robru> veebers, yep, exactly that one
[00:37] <veebers> robru: awesome, thanks
[00:37] <robru> veebers, you're welcome
[00:38] <sergiusens> robru, ok, I'm tired of the changelog mess; can you dput lp:~phablet-team/ofono/ubuntu to silo 7?
[00:38] <robru> sergiusens, sure, sorry
[00:38] <cyphermox> veebers: let us know what your bug is though, maybe we can fix it now
[00:38] <cyphermox> sergiusens: heh?
[00:39] <sergiusens> robru, I haven't run reconfig yet
[00:39] <robru> sergiusens, ok
[00:39] <veebers> cyphermox: just posting it, it's re: closing bugs that are attached to MRs that are in the silo and then merged.
[00:39] <cyphermox> ah, ok
[00:39] <sergiusens> cyphermox, the changelog generated goes to the beginning of times it feels
[00:39] <robru> cyphermox, yeah, it's a known bug with the changelog logic.
[00:39] <cyphermox> ok
[00:39] <imgbot> [00:40] <robru> sergiusens, wait, did you merge the MP manually into that branch? because that's the destination branch right?
[00:41] <sergiusens> robru, yeah; that's why I said; do a source upload into the train instead of an MR
[00:42] <robru> sergiusens, ok no worries
[00:42] <sergiusens> robru, I might be doing it wrong; for which we can course correct
[00:43] <robru> sergiusens, yeah i'm not sure whats going on. need didrocks to investigate. i reported that bug already and assigned it to him
[00:51] <robru> cyphermox, so what, did we decide to block mir then?
[00:51] <robru> sergiusens, ok, uploaded
[00:52] <cyphermox> robru: no, I just want to understand what's going on
[00:52] <robru> cyphermox, thing is, I gotta run for dinner in about 15. i vote for publishing since it looked good in my testing on the device
[00:52] <cyphermox> robru: if you've tested it on desktop too then I guess it's fin to releady
[00:52] <sergiusens> robru, thanks
[00:53] <robru> cyphermox, yeah, didn't test on desktop :-/
[00:53] <cyphermox> ok
[00:53] <cyphermox> alright, publish
[00:53] <cyphermox> I believe in sharing the pain, people should be responsible for the code they break
[00:53] <robru> heheh
[00:54] <cyphermox> I think it's probably safe, but I'm worried about upgrade path
[00:54] <robru> cyphermox, ok, i hit publish, when didrocks reverts it overnight i'll blame it all on you. thanks ;-)
[00:54] <cyphermox> hehe
[00:54] <cyphermox> that's not what I meant by sharing the pain ;)
[00:54] <robru> cyphermox, :-P
[00:55] <sergiusens> robru, cyphermox you can say you pushed it together :-P
[01:00] <robru> cyphermox, et al ok I gotta run for dinner for a couple hours, i'll check in a bit later but it'll probably be around when the europeans are waking up anyway.
[01:03] <cyphermox> ok
[01:15] <bfiller> robru: can you make a silo for line 50 (and press build) when you come back?
[01:21] <bfiller> robru: also, silo-15 gallery-app, seems it's failing arm64, powerpc and ppc64el. We have to support those arch's now?
[01:22] <cjwatson> We should support all the arches we can, but you only have to support ones that previously built in trusty
[01:23] <cjwatson> however:
[01:23] <cjwatson>  gallery-app | 0.0.67+14.04.20140307-0ubuntu1   | trusty/universe          | source, amd64, arm64, armhf, i386, powerpc, ppc64el
[01:30] <cjwatson> that's an odd set of failures though.  what's adding the -lz?
[01:32] <cjwatson> the -lz is present on amd64 too, but there, zlib1g-dev is installed as a build-dep (maybe not direct)
[01:35] <cjwatson> libgles2-mesa-dev -> libmirclient-dev -> [...] -> zlib1g-dev, so it'll only work on arches with mir the way it is at the moment
[01:41] <cjwatson> I blame libmediainfo
[01:46] <cjwatson> Could somebody please retry the failing gallery-app builds in silo-15 once "rmadison -s trusty libmediainfo-dev" reports 0.7.67-2ubuntu1 on those architectures?
[01:46] <cjwatson> https://launchpad.net/ubuntu/+source/libmediainfo/0.7.67-2ubuntu1
[01:46] <cjwatson> And let bfiller know about that when he comes back
[02:29] <cyphermox> cjwatson: ok
[02:52] <thomi> doanac`: plars: Are there known issues with the mako-06 device in the lab? I'm seeing this: http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/label=mako-06/78/console
[02:52] <thomi> I guess rfowler_ might know as well ^^
[02:53] <thomi> "ERROR:phablet-flash:Device either not connected, doesn't have adb enabled or the property system cannot be accessed. Make sure the device is booted into the operating system and that adb is working correctly."
[02:58] <plars> error: device not found
[02:58] <plars> thomi: looks like it died
[02:58] <thomi> plars: what can I do to get a device for that job again?
[02:59] <plars> thomi: open an RT for rfowler_ to take a look at it in the morning, and we can try to find a different one for it to use
[02:59] <thomi> plars: ok, what's the rt address again?
[03:00] <plars> thomi: ubuntu-platform@rt.canonical.com and cc him on it
[03:00] <thomi> plars: thanks. I guess I'll give up for today then :)
[03:01] <plars> thomi: let me see if we can get it on a different device for now
[03:04] <plars> thomi: ok, retry now, I moved it to mako-07
[03:04] <thomi> cool, thanks, I'll re-run
[03:06] <plars> thomi: oh, that's not going to work
[03:06] <plars> let me look at this job
[03:07] <thomi> yeah, it didn't like that
[03:07] <plars> thomi: they moved everything around today, and it wasn't linked the way we thought it would be
[03:09] <imgbot> [03:13] <plars> thomi: oh, I see the problem
[03:13] <plars> thomi: do you know why it's pulling a specific revision of the touch branch?
[03:14] <thomi> plars: ahh, I think that's because doanac`broke something, and said we should use a specific revision that wasn't broken
[03:14] <thomi> If that's been fixed, I guess we can remove that
[03:14] <plars> thomi: ok, well I don't know what was broke before, but I know that the version you are on is incompatible with the way they moved images around now
[03:15] <thomi> plars: the thing that broke was that PPAs weren't getting installed
[03:15] <plars> thomi: so we can try the latest if that won't cause you problems, and if it still causes problems we can just override the image_opts
[03:15] <plars> ah
[03:16] <plars> thomi: well, nothing new was checked in before today since...
[03:16] <plars> thomi: March 7th?
[03:16] <plars> thomi: was this before then?
[03:16] <thomi> veebers: you dealt with that ^^
[03:16]  * veebers reads backlog
[03:16] <veebers> one sec
[03:20] <veebers> plars: I was told revno 190 was the one we needed to use as 191 broke what we were doing
[03:21] <veebers> (i'm just digging through my logs to try get more details)
[03:22] <veebers> plars: in case it helps, this is the bug that was filed: https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1290937
[03:22] <plars> doesn't look like there was a fix since then
[03:22] <plars> ok, let me just try overriding the image opts
[03:22] <plars> that should get us through for now
[03:24] <plars> thomi: try again?
[03:24] <thomi> sure
[03:25]  * thomi watches http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/80/label=mako-07/console
[03:30] <thomi> looks happier plars, thanks for your help.
[03:31] <plars> thomi: anytime :)
[03:31] <thomi> veebers: I gott go AFK for a few minutes, I wonder if I could get you to keep an eye on that please?
[03:31] <thomi> plars: careful, I live in an odd timezone. "anytime" for me probably means something very different than it does to you :)
[03:31] <veebers> thomi: sure
[03:31] <thomi> thanks
[04:14] <imgbot> [04:37] <robru> hey i'm back briefly, anybody need anything?
[05:10] <Mirv> hello
[05:12] <rsalveti> Mirv: hey, had to push an update to qtbase, to make the emulator to work again: https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.2.1+dfsg-1ubuntu8
[05:12] <rsalveti> next time we should also put the emulator to the list of required targets to be tested
[05:13] <rsalveti> Mirv: it's a simple fix, as most of that patch was already upstream, but it was missing one piece that is only available in the android backend
[05:13] <rsalveti> and in our case we need to use it with the generic one
[05:13] <rsalveti> would be nice to get this to upstream as well, will check tomorrow
[05:14] <Mirv> rsalveti: ok, I'll fetch it to the the bzr
[05:14] <Mirv> it seems another upload may be needed, there's a fix for the font glyph problem appearing from upstream
[05:21] <Mirv> rsalveti: the qtlocation/qtpositioning is.. complicated. they both come from upstream tarball 'qtlocation', but all the while qtlocation5-dev has included the headers for both. but Debian changed this, since in addition to all that, upstream only supports Qt Positioning at this time, so Debian split the headers
[05:21] <Mirv> all things counted, when we sync with Debian, I expect we'll have qtlocation5-dev depending on qtpositioning5-dev
[05:22] <Mirv> and Debian isn't shipping the "Qt Location" part of "qtlocation" upstream even, since it depends on qt3d which isn't released or maintained and is being rewritten :P
[05:22] <Mirv> in short, qtpositioning is what people are mostly probably using but they think it's called qtlocation
[05:23] <Mirv> rsalveti: reading the next lines, yeah probably SDK should be updated somehow, I guess we should be shipping the positioning part at least now, since we've a plugin for it even in qtubuntu-sensors
[05:24] <Mirv> aha, and Zoltan will take care of it :D backlog reading...
[05:25] <Mirv> oh, right the module thing ybon found out about.. yep, it's probably QtPositioning, coming from qtdeclarative5-qtpositioning-plugin, related to the confusion described above ^
[05:27] <Mirv> all our git snapshot modules had the text "WARNING: This module is not an official part of Qt 5, but instead a gitsnapshot of an ongoing development. The package is very likely tochange in a binary incompatible way, and no guarantees are given.", and indeed qtlocation now gives an example of why
[05:27] <Mirv> at least now the Positioning is released by upstream
[05:40] <rsalveti> yeah
[06:35] <Mirv> robru: if you've gone to sleep as you should be I'll run merge and clean for the friends
[06:35] <robru> Mirv, sure, thanks
[06:35] <robru> Mirv, I tried to do it earlier but it was stuck in proposed for *so* long.
[06:35] <robru> Mirv, also only 11:30 here ;-)
[06:36] <robru> Mirv, working on a personal thing though, not a workaholic ;-)
[06:36] <Mirv> robru: bah :D
[06:37] <Mirv> robru: good that you've switched to hacking on personal stuff at least :)
[06:37] <robru> heheh
[06:37] <Mirv> merge&clean running
[06:56] <didrocks> cihelp: seems we didn't get the last 2 images test results, mind looking?
[06:56] <didrocks> Mirv: maybe you already ask and got some infos?
[06:56] <ybon> backloging… Mirv: so at this time I still should be importing QtLocation 5.0 to get the QML Map type?
[06:56] <Mirv> didrocks: no, I only just a moment ago started boggling that the 241 results are quite old
[07:01] <Mirv> ybon: ..right, the qtlocation itself still seems to have that, and it's called QtLocation 5.0 still because it's not "released" (supported) by upstream, while QtPositioning is 5.2
[07:01] <vila> didrocks, Mirv: heads down for the demo but lp had a *massive* breakage yesterday including the buildds and giving non-sense feedback, I don't have precise timing but most of last night builds are borked
[07:01] <didrocks> vila: can you try just a rerun on the tests to see if they starts?
[07:02] <vila> didrocks: nope, sorry
[07:02] <ybon> Mirv: ok, thanks for the clarification :) I've a strange error about a Nokia key missing since I've upgraded to 5.2 my libs, but I will have a better look at this tonight
[07:02] <ybon> thanks again :)
[07:04] <didrocks> vila: who can do that or will be the vanguard to help and unblock the touch image today?
[07:08] <Mirv> ybon: np, thanks for asking :)
[07:23] <vila> didrocks: no idea, I have barely started my day, ev is on site, psivaa will be the vanguard but given wgrant's explanations in #ci (Everything was broken when some LP machines ENOSPCd for 90 minutes and IS didn't notice.), just re-runs may not be enough
[07:23] <vila> didrocks: I haven't even checked yet if lp is back for good
[07:24] <didrocks> vila: lp is good, packages are building in distro as well
[07:24] <wgrant> vila: LP's been fine for just under 10 hours now
[07:24] <wgrant> Any builds started in the last 10 hours - 5 minutes are fine
[07:25] <vila> wgrant, didrocks: great, one less issue to care about
[07:25] <didrocks> ok, I guess there is no other option than waiting on psivaa then (and loose 1h30 of testing)
[07:26] <didrocks> asac: FYI, I don't feel confident as we are blind for the past 10h in term of publication and image building (and quite a lot entered, including a new Mir), so holding up on releasing
[07:46] <sil2100> psivaa, didrocks: what's up with test results for 20140318 on smoketesting?
[07:47] <didrocks> sil2100: yeah, we don't know, see http://irclogs.ubuntu.com/2014/03/18/%23ubuntu-ci-eng.html#t06:56
[07:47] <didrocks> sil2100: seems nobody looked at that, even if LP and IS is up for the past 10h
[07:48] <didrocks> and nobody in the CI team is available right now to help us
[07:48] <sil2100> Crap
[07:49] <sil2100> But I see we had a similar problem yesterday with the 20140317 image - wonder what's causing the provisioning to fail
[07:51] <didrocks> yeah
[07:54] <Mirv> FYI rsalve_ti landed a qtbase change with an emulator fix, while the one in the CI Train is from me picking up upstream patches to fix the newline glyph issue
[07:55] <didrocks> ah great!
[07:55] <didrocks> so one less on the critical list?
[07:56] <Mirv> yes, now that it was made critical yesterday. I also marked terminal as fixed as it seems to work on #243
[07:57] <didrocks> great
[07:57] <Mirv> weird that the calendar app AP problems didn't show up in pre-landing testing, it was run as part of elopio's AP test runs
[07:58] <Mirv> also, the music app was supposed to have only one AP problem with a proposed fix, but it seems to be more than that
[07:59]  * sil2100 is upgrading to latest image
[07:59] <asac> didrocks: ok
[07:59] <asac> vila: can you learn what to resurrect our test infra? Seems we have a too light know how spread in EU timezone on this
[07:59] <asac> psivaa: ^
[08:02] <sil2100> Now this is strange - #241 theoretically has the new unity8 but still the url-dispatcher test is failing
[08:02] <vila> asac: it's not about learning, it's about available time, our on site demo is today and guess what, we have some firedrills ;) OTP right now with hp support
[08:02] <sil2100> Even though psivaa ran the branch last week and it didn't encounter the failure
[08:03] <asac> ogra_: ^^
[08:03] <asac> vila: ic
[08:03] <asac> ogra_: so nothing works in infra for 2 images
[08:03] <asac> ogra_: i supposed this has to do with the system-image update thingy?
[08:05]  * sil2100 would  really appreciate some latest-image test results
[08:06] <asac> guess you have to run locally
[08:07] <asac> vila: can you give us the old phablet-flash of raring that is used in the infra?
[08:07] <asac> would be cool if sil could try that locally
[08:07] <asac> sil2100
[08:09] <tvoss> good morning
[08:09] <asac> https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/159/console
[08:09] <asac> looking at that it feels the device just died
[08:09] <asac> and adb is not avail
[08:11] <didrocks> I wonder about 2 things
[08:11] <didrocks> let me try if phablet-flash is still working today
[08:11]  * didrocks tries on his device
[08:11] <vila> asac: hp issue escalated, I'm blocked on that front :-( I may as well try to help here but I may switch again on short notice
[08:11] <vila> yup mako-11 is dead according to nagios
[08:11] <didrocks> ah, so should be only that, no device
[08:13] <vila> asac: raring ? or trusty ?
[08:13] <vila> oh raring
[08:13] <vila> vila@ashes:~$ apt-cache policy phablet-tools
[08:13] <vila> phablet-tools:
[08:13] <vila>   Installed: 1.0+14.04.20140122-0ubuntu1
[08:13] <vila>   Candidate: 1.0+14.04.20140122-0ubuntu1
[08:13] <vila>   Version table:
[08:13] <vila>  *** 1.0+14.04.20140122-0ubuntu1 0
[08:13] <vila>         500 http://ppa.launchpad.net/phablet-team/tools/ubuntu/ raring/main amd64
[08:14] <asac> didrocks: seems so
[08:14] <asac> didrocks: do you know how to reroute device?
[08:14] <didrocks> asac: no, I don't have that knowledge
[08:15] <asac> didrocks: do you have the old phablet-flash?
[08:15] <asac> the one above?
[08:15] <asac> it is still suspicious that all devices died
[08:15] <didrocks> asac: not the raring one, I can easily downgrade to try to flash I guess
[08:15] <didrocks> let me try with that old version
[08:15] <didrocks> so the flashing happens on raring machines, right?
[08:16] <asac> didrocks: yeah :/
[08:16] <didrocks> hum, but launchpad doesn't have them at it's EOL
[08:16] <asac> didrocks: right
[08:16] <wgrant> You can still grab the binaries if you look
[08:16]  * didrocks digs to archives
[08:16] <wgrant> IIRC we haven't completely killed them from LP yet
[08:16] <didrocks> wgrant: is there any url pattern in LP?
[08:16] <didrocks> or I need to poke at random strings in librarian? :p
[08:16] <asac> i am seeing phablet-flash ubuntu-system -b --channel ubuntu-touch/trusty-proposed ... who knows if that option really follows the compatibility links
[08:17] <wgrant> What's the binary name?
[08:17] <didrocks> wgrant: source package is phablet-tools
[08:17] <didrocks> we want 1.0+14.04.20140122-0ubuntu1
[08:17] <didrocks> https://launchpad.net/ubuntu/+source/phablet-tools/1.0+14.04.20140122-0ubuntu1
[08:17] <didrocks> wgrant: ah, you're right, no spring cleaning yet! :)
[08:17] <wgrant> didrocks: phablet-tools never existed in raring
[08:17] <asac> wgrant: ppa
[08:17] <didrocks> wgrant: yeah, it was a ppa
[08:18] <asac> 09:13 < vila>         500 http://ppa.launchpad.net/phablet-team/tools/ubuntu/ raring/main amd64
[08:18] <didrocks> but no worry, it was in saucy
[08:18] <asac> wgrant: ^
[08:18] <asac> sh cool
[08:18] <wgrant> Unless you mean in a PPA, in which case it's under the normal PPA expiry rules -- nothing to do with raring's obsolescence :)
[08:18] <asac> ah
[08:18] <didrocks> with the same version
[08:18] <asac> :)
[08:18] <didrocks> so I got it
[08:18] <asac> wgrant: it was the last version in raring ppa pocket (so without EOL it wouldnt get removed)
[08:18] <asac> anyway, seems we have the same code
[08:18]  * didrocks installs old version
[08:18] <asac> could still be adb incompatible :)
[08:18] <wgrant> We don't (yet) erase stuff from PPAs on EOL, for this sort of reason.
[08:19] <asac> ah so we could find it?
[08:19] <asac> let me dig
[08:19] <didrocks> I have it :p
[08:19] <didrocks> if you read me
[08:19] <didrocks> https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5488906
[08:19] <asac> http://ppa.launchpad.net/phablet-team/tools/ubuntu/pool/main/p/phablet-tools/phablet-tools_1.0+14.04.20140122-0ubuntu1_all.deb
[08:19] <asac> seems its still there
[08:19] <asac> good to know
[08:20] <didrocks> so, it's downloading
[08:20] <didrocks> the image
[08:20] <didrocks> and INFO:phablet-flash:Device detected as mako
[08:20] <Mirv> sil2100: do you know about those thostr's old landings toward the beginning of the spreadsheet? I'm not sure what's up with them, so I've only assigned silos to the new requests
[08:20] <asac> didrocks:  with the command above?
[08:20] <didrocks> asac: yeah, that exact command
[08:21] <asac> then i guess something in infra happened physically and rerouting device would do
[08:21] <didrocks> yep
[08:21] <asac> unless everything is off of course
[08:21] <sil2100> Mirv: most of them aren't ready, as Ready is No - there is one that was 'Yes' but it said it's been pushed back
[08:21] <asac> didrocks: https://wiki.canonical.com/UbuntuEngineering/CI/Playbook
[08:21] <Mirv> also, thomir's line 40 landing is blocking two more upstart-app-launch landings, but apparently all upstart-app-launch updates are thought to be a bit tricky so they're blocked until green image?
[08:21] <didrocks> asac: jenkins isn't, it's in the same lab and network IIRC
[08:21] <asac> didrocks: https://wiki.canonical.com/UbuntuEngineering/CI/Playbook#Touch_Image_Smoke_Device_Offline
[08:21] <sil2100> Mirv: I didn't assign them because of those reasons - I guess it's best if we wait for thostr to pop up and decide the fate of those landings
[08:22] <asac> didrocks: that recipe might help
[08:22] <Mirv> sil2100: ok, line 11 and 12 are both "Yes". I'm just curious, thostr can request when he needs them of course.
[08:22] <didrocks> asac: I looked at it already, it's only about rerunning the tests
[08:22] <didrocks> asac: I don't see a reprovision or did I miss anything?
[08:22] <asac> didrocks: you miss it
[08:23] <asac> didrocks: #Touch_Image_Smoke_Device_Offline
[08:23] <didrocks> asac: setting the node offline?
[08:23] <asac> yes
[08:23] <asac> thats what it is it seems
[08:23] <asac> Next, report the failure to Rick Fowler, so he can take a look and recover the device if possible
[08:23] <vila> mako-11 has just been marked offline
[08:23] <asac> vila: nice
[08:23] <asac> now someone need to rerun
[08:23] <asac> Next, report the failure to Rick Fowler, so he can take a look and recover the device if possible
[08:23] <asac> Next, report the failure to Rick Fowler, so he can take a look and recover the device if possible
[08:23] <asac> lol
[08:23] <asac> http://q-jenkins.ubuntu-ci:8080/job/trusty-touch-mako-smoke-daily/
[08:24] <didrocks> vila: you are running this job? ^
[08:24] <sil2100> Mirv: line 12 is a bit risky I would say in the sense that url-dispatcher is not on the touch standing FFe, and I would need to check those two merges closer
[08:24] <sil2100> Mirv: since on my first look they didn't seem to be bug-fixes, that's why I skipped that - but maybe it's best to simply look into those
[08:24] <didrocks> asac: yeah, so that's what I told, I maybe don't have the jenkins right to set a node off (as I don't see them)
[08:25] <sil2100> Mirv: (no bugs assigned to those merges)
[08:25] <asac> didrocks: ok, but you can rerun job, right?
[08:25] <didrocks> yeah
[08:25] <didrocks> I was wondering if vila wasn't on that as he started the recovery procedure
[08:25] <asac> didrocks: he is on a call
[08:26] <didrocks> ok, running it then
[08:26] <asac> so guess might not see the pings quickly
[08:26] <asac> thanks
[08:26] <asac> lets cross fingers :)
[08:26] <asac> otherwise reread the log
[08:26] <asac> must be reproducible
[08:26] <vila> didrocks: thanks
[08:26] <didrocks> let's see
[08:26] <didrocks> asac: sounds good
[08:26] <didrocks> vila: ^
[08:26] <didrocks> vila: I'll let you finish the procedure quietly
[08:26] <vila> sry filing ticket for rfowler
[08:27] <didrocks> weird that manta as well
[08:27] <asac> right
[08:27] <didrocks> I only look at mako for now, I'll let the CI team recovering from the rest if they analyze it
[08:27] <didrocks> but this phablet-flash thing will shoot in our feet soon
[08:28] <asac> of coruse
[08:28] <asac> thats well known
[08:28] <asac> thats why i triple asking yesterday to pipeclean test it
[08:28] <asac> while stgraber was still on
[08:28] <asac> so they could roll back
[08:28] <didrocks> yeah :)
[08:28] <asac> but lets hope its not that
[08:28] <didrocks> asac: was the change announced anywhere and I missed it?
[08:28] <asac> oth i dont see a pipeclean run that succeeded
[08:28] <asac> otoh
[08:29] <asac> didrocks: i picked it up on IRC
[08:29] <didrocks> I'm not even sure what's changed
[08:29] <asac> didrocks: was meant to be a silent compatible change with zero impact
[08:29] <asac> :)
[08:29] <didrocks> ok, that's… well… reconforting :)
[08:29] <asac> didrocks: i think reorg of folder structure with compatibility links was the plan
[08:29] <didrocks> ah, that one
[08:29] <didrocks> ok, it was discussed some weeks ago
[08:29] <asac> seems the job picks up the data from system image
[08:29] <didrocks> just not about the D day
[08:29] <didrocks> yeah
[08:30] <asac> cool
[08:30] <asac> lets see if it trashed
[08:30] <didrocks> it's not the raring version in fact
[08:30] <asac> but guess we should just offline the other 2 types as well
[08:30] <didrocks> it's a version which is picking the real infos
[08:30] <didrocks> (the first ones hardcoded the paths)
[08:30] <asac> didrocks: could be they hacked it
[08:31] <asac> seems its going good enough
[08:31] <asac> restart manta and flo?
[08:31] <asac> wait
[08:31] <asac> lets see how the first fail looked
[08:31] <didrocks> without the device being offline?
[08:31] <mhr3> sil2100, ok to publish 001?
[08:31] <asac> 158
[08:31] <sil2100> mhr3: looking
[08:31] <asac> didrocks: righyt
[08:31] <asac> so dont do that
[08:31] <asac> didrocks: http://q-jenkins.ubuntu-ci:8080/job/trusty-touch-mako-smoke-daily/158/console
[08:31] <asac> didrocks: that thing also downloaded, but then trashed the device
[08:32] <sil2100> mhr3: let me do a test spin of that and then release
[08:32] <asac> so lets see if mako goes dead now again
[08:32] <didrocks> asac: yeah, so first time it was picked up
[08:32] <didrocks> and then dead
[08:32] <didrocks> it went further at least :p
[08:32] <didrocks> on mako
[08:33] <asac> further?
[08:33] <asac> sure?
[08:33]  * asac wits for a few more lines before claiming success
[08:33] <didrocks> asac: yeah, it was blocked on the reboot to recovery
[08:33] <didrocks> here, it rebooted to recovery and flash
[08:34] <didrocks> so let's see if full install is done
[08:34] <Mirv> sil2100: ok, thanks for the analysis
[08:35] <didrocks> sil2100: mind deploying latest cu2d to preprod and prod? I'm watching now for arm64
[08:35] <didrocks> the diff is:
[08:35] <didrocks> -ARCHS_TO_UNCONDITIONALLY_IGNORE = set(['arm64'])
[08:35] <didrocks> +ARCHS_TO_UNCONDITIONALLY_IGNORE = set([])
[08:37] <didrocks> asac: tests starting
[08:39] <asac> didrocks: cool. so maybe one more device offline?
[08:39] <didrocks> asac: yeah, I don't find access to the nodes on that jenkins, so I guess we'll need vila or psivaa to set them back up
[08:40] <didrocks> asac: at least, the primary target, mako is back
[08:40] <asac> vila: can you offline manta and flo too?
[08:40] <psivaa> didrocks: asac: just logging in to the server,
[08:40] <asac> vila: when convenient
[08:40] <asac> vila: ah ignore
[08:40] <asac> psivaa: :)
[08:40] <asac> high
[08:40] <asac> hi
[08:40] <asac> hehe
[08:40] <psivaa> :)
[08:40] <asac> psivaa: we need manta and flo offlined
[08:40] <asac> and rerun
[08:40] <asac> seems mako recovered that wayt
[08:40] <sil2100> didrocks: ok, been testing something on my phone
[08:41] <didrocks> asac: mako rebooted multiple times successfully
[08:41] <asac> right
[08:41] <sil2100> didrocks: by cu2d you mean, citrainish?
[08:41] <didrocks> sil2100: yep
[08:41] <psivaa> asac: ok, let me take a look
[08:41] <asac> didrocks: so i think the image that busted stuff was bogu
[08:41] <didrocks> sil2100: deploy-deploy job :)
[08:41] <asac> s
[08:41] <didrocks> can be
[08:41] <asac> didrocks: guess someone did a direct injection of something and fixed it but didnt know how to Fix the infra
[08:42] <asac> lxc-android-config
[08:42] <asac> http://people.canonical.com/~ogra/touch-image-stats/20140317.3.changes
[08:42] <asac> hmm. but tahts still 149
[08:42] <asac> so guess not:)
[08:42] <sil2100> didrocks: so, preprod, prod and deploy_deploy :) ?
[08:42] <didrocks> sil2100: yeah
[08:42] <sil2100> Running!
[08:43] <didrocks> asac: well, the issue started 2 images ago actually
[08:43] <vila> didrocks: http://q-jenkins.ubuntu-ci:8080/computer/flo-01/ ? From http://q-jenkins.ubuntu-ci:8080/computer/
[08:43] <vila> asac, didrocks : which manta and flo ? All of them ?
[08:43] <asac> didrocks: the changs is from 2 times ago
[08:43] <asac> afaics
[08:43] <asac> otherwise it woudl be http://people.canonical.com/~ogra/touch-image-stats/20140317.2.changes
[08:43] <asac> vila: no
[08:43] <asac> vila: ignore
[08:43] <asac> vila: psivaa is on it
[08:44] <didrocks> asac: yeah, it will be 20140317.2
[08:44] <asac> didrocks: ok so guess nothing on software side
[08:44] <asac> must be power or something in lab
[08:44] <asac> who knows :)
[08:44] <asac> or jenkins was temp down or so
[08:44] <didrocks> I doubt that node connection is bound to that
[08:45] <didrocks> it's really weird, I don't trust in coincidence for the 3 being offline at the same time
[08:45] <asac> right
[08:45] <asac> didrocks: could still be system-0images
[08:45] <asac> that got fixed after
[08:45] <vila> asac: right, just sync with him, switching back
[08:45] <vila> didrocks: good luck !
[08:46] <didrocks> vila: thanks :)
[08:46] <vila> didrocks: and sorry
[08:46] <asac> thanks1
[08:47] <asac> didrocks: whatever it was is fixed or its a second-time flash thing
[08:48] <asac> and was introduced one image before the one going red :)
[08:48] <didrocks> yeah
[08:53] <psivaa> didrocks: asac: some other devices of manta and flo are flashing with 243.. looks like 242 had flashing issues?
[08:57] <sil2100> mhr3: 001 looks good!
[08:57] <sil2100> mhr3: publishing
[09:03] <sil2100> didrocks: packaging ACK -> http://162.213.34.102/job/landing-001-2-publish/51/artifact/packaging_changes_unity-scope-click_0.1+14.04.20140317-0ubuntu1.diff <- there seems to be dh_auto_test removed, checked the related commit and the rationale is: "Don't run the vala tests during package build any more"
[09:04] <didrocks> sil2100: did you ask upstream why first?
[09:04] <didrocks> at least, start with the lander :p
[09:06] <sil2100> mhr3: my man!
[09:06] <sil2100> mhr3: y u not like runnin' vala tests?
[09:06] <sil2100> mhr3: y u do dis?
[09:21] <didrocks> psivaa: "due to a bad image", the image didn't boot up at all?
[09:23] <psivaa> didrocks: i have not seen the devices, but given that all 3 devices failed after 'INFO:phablet-flash:Clearing /data and /cache' it's most likely the image was bad someway
[09:24] <psivaa> didrocks: this was image with image 242.
[09:25] <asac> see -touch
[09:25] <asac> seems there was an issue
[09:25] <didrocks> psivaa: do we know exactly why/how? seems it worth an investigation
[09:25] <didrocks> here
[09:25] <didrocks> ok
[09:25] <asac> code was shared, probably even deployed
[09:25] <asac> but not more
[09:26] <ogra_> right, i know that plars and sergio shared a chnage for theior phablet-flash since they  wouldnt have the time to do the swiatch to ubuntu-device-flash
[09:27] <ogra_> sigh, cant type today
[09:29] <psivaa> didrocks: i still dont have the invite for the LTF meeting
[09:30] <didrocks> psivaa: did you accept the meeting?
[09:30] <psivaa> didrocks: there was no email for me
[09:30] <didrocks> seems only davmor2 accepted it
[09:30] <didrocks> argh
[09:30] <sil2100> hmmm
[09:30] <sil2100> I don't see an invite
[09:30] <didrocks> not sure why google didn't send it…
[09:30] <sil2100> duh ;)
[09:31] <didrocks> https://plus.google.com/hangouts/_/canonical.com/landing-meeting
[09:31] <sil2100> Found it through google
[09:32] <didrocks> popey: ^
[09:42] <ogra_> asac, so looking closer, image 242 and 243 *should* have the fix in the infra ... but apparently there are actual devioce issues
[09:47] <ogra_> phablet-flash ubuntu-system -b --channel ubuntu-touch/trusty-proposed
[09:47] <ogra_> error: device not found
[09:47] <ogra_> asac, from the 243 logs ^^^^
[09:47] <ogra_> (so the new channel prefix hack is in but there is no device)
[09:48] <ogra_> (and it is the same for all devices)
[09:49] <seb128> you guys should think about archiving some of the landed lines on the CI train list
[09:50] <seb128> it would make the list easier to browse
[09:50] <ogra_> on the spreadsheet you mean
[09:50] <ogra_> ?
[09:50] <seb128> yes
[09:50] <ogra_> didrocks, ^^^^
[09:56] <sergiusens> didrocks, ogra_ is the expectation that now all debs have to build for all arches?
[09:57] <ogra_> sergiusens, well, at least all that have built before, not sure if the expectation for the initial build has changed, cjwatson might know
[09:58] <sergiusens> I can see it as a goal that by x date they should; but not sure people had plans for it
[09:59] <davmor2> ogra_, popey: open settings/terminal and rotate the phone on both of those apps do they align corrently for me it gets nearly upright and stalls and then a few seconds latter will be fully upright
[09:59]  * sergiusens is glad to see a run with the gallery at 100%
[09:59] <ogra_> davmor2, i have to wait til after the meeting ... hangouts and flashing/downloading at the same time dont work great here :)
[10:04] <cjwatson> ogra_: it's still all that have built before
[10:04] <cjwatson> ogra_:
[10:04] <cjwatson> https://wiki.ubuntu.com/ProposedMigration
[10:04] <ogra_> yup
[10:04] <cjwatson> ah, nobody rebuilt gallery-app
[10:04] <cjwatson> let me fix that
[10:05] <asac> ogra_: my understanding is that we busted the device, then noone put that device offline
[10:05] <asac> now the new build is spinning
[10:06] <ogra_> well, i dont get how we busted the device ... the foremer installs worked
[10:06] <ogra_> *former
[10:06] <bzoltan1> asac:  the newline glyph bug is fixed and verified
[10:06] <asac> bzoltan1: nice one... the MP up?
[10:06] <asac> alreadyu in landing train?
[10:06] <bzoltan1> asac: Mirv is about to land it
[10:06] <sil2100> mhr3: hey!
[10:06] <ogra_> + phablet-flash ubuntu-system -b --channel ubuntu-touch/trusty-proposed
[10:06] <ogra_> INFO:phablet-flash:Device detected as mako
[10:07] <bzoltan1> asac: Silo2 has it
[10:07] <plars> ogra_, asac, psivaa: so after applying all the fixes yesterday, we saw image 241 run through successfully
[10:07] <ogra_> asac, thats 241 ^^^^
[10:07] <plars> so my guess is that something fell apart at 242
[10:07] <plars> in the image
[10:07] <popey> http://popey.com/~alan/phablet/device-2014-03-18-100621.png go home settings, you're drunk!
[10:07] <ogra_> which is interesting since manual installs seem to work
[10:07] <didrocks> asac: FYI, possible Mir regressoin
[10:08] <didrocks> asac: getting confirmation
[10:08] <asac> plars: that image doesnt really look suspicious, but yes, could be the reason
[10:08] <asac> must be something that busted mako and maguro though
[10:08] <asac> and flo :)
[10:08] <davmor2> popey: that looks straight
[10:08] <plars> it seemed to affect us across the board, so rfowler_ is going to be busy today I think
[10:08] <asac> didrocks: was there a mir landing?
[10:08] <ogra_> asac, that image was the first one after stephanes change
[10:08] <popey> davmor2: you need your eyes tested ☻
[10:08] <asac> plars: ogra_: so who is right of you? :)
[10:08] <didrocks> asac: yeah, I really warned Keving about it
[10:08] <popey> davmor2: it straightens up when i run mirscreencast
[10:08] <ogra_> asac, so the issue isnt caused by the s-i change at all
[10:08] <asac> ok
[10:08] <asac> good
[10:08] <didrocks> asac: but he told it was mostly affecting desktop only and really really testing it
[10:08] <asac> then what happend in 242?
[10:09] <ogra_> but there is an issue still :)
[10:09] <didrocks> asac: and we were doomed to block him
[10:09] <asac> mir landed?
[10:09] <didrocks> 243
[10:09] <didrocks> mir landed
[10:09] <ogra_> yup
[10:09] <didrocks> but now apps are really slow to start
[10:09] <asac> but 242 also failed?
[10:09] <davmor2> popey: it's not perfectly straight but it's closer than I get sometimes :)
[10:09] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/20140318.changes
[10:09] <ogra_> 243^^^
[10:09] <didrocks> are some apps don't show up until you touch the screen
[10:09] <didrocks> (all blank)
[10:09] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/20140317.3.changes
[10:09] <ogra_> 242^^^
[10:09] <didrocks> system-settings and click-update
[10:10] <asac> right. so 242 somewhat failed after downloading bits
[10:10] <asac> to install
[10:10] <didrocks> seb128: FYI, if you see some issues at startup, it's known ^
[10:10]  * ogra_ will hack the bot today to put proper symlinks in place for the changelogs so we have the right numbers
[10:10] <asac> 243 then couldnt connect anymore
[10:10] <asac> i really suspect the problem was injected in 242
[10:10] <ogra_> yes
[10:10] <asac> but *shrug*
[10:10] <asac> so http://people.canonical.com/~ogra/touch-image-stats/20140317.3.changes
[10:10] <ogra_> but the package changes in 242 look harmless
[10:10] <asac> not much was going on there
[10:10] <asac> right
[10:10] <asac> thats why i dont know
[10:10] <didrocks> seb128: ogra_: I'll archive the spreadsheet soon
[10:11] <asac> still feels like something in the lab happened
[10:11] <asac> or with system-image :)
[10:11] <asac> hehe
[10:11] <asac> (j.k.)
[10:11] <didrocks> asac: we are focusing on the regression for now
[10:11] <seb128> didrocks, thanks
[10:11] <didrocks> asac: but reverting Mir isn't easy…
[10:11] <didrocks> if needed
[10:12] <didrocks> as per ABI break
[10:12] <asac> right
[10:12] <didrocks> davmor2: confirming regression btw
[10:13] <didrocks> and yeah, all apps are really slow to start as well
[10:13] <psivaa> didrocks: as to why the results are not syncing to the dashboard, there seems to be an issue and i dont have access to the server that's running the dashboard.
[10:13] <didrocks> come on, how that was tested!
[10:14] <didrocks> and then, the same people are arguing on the "risk" terminology
[10:14] <didrocks> asac: oh as well, we don't have CI results on the dashboard anymore
[10:14] <ogra_> check for apparmor denials in syslog
[10:14] <psivaa> didrocks: all those that have access are now in US timezone. cjohnston should be up soon, i'll ask him
[10:14] <didrocks> psivaa: ok, thanks for tracking that
[10:14] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/20140318.changes has a new apparmor-easyprof-ubuntu
[10:15] <popey> davmor2: yeah, I get the same as you, but as I said, when I run mirscreencast it straightens before I get a screenshot
[10:15] <didrocks> ogra_: no DEN in my syslog
[10:15] <popey> davmor2: i think this is related to the app being blank, i suspect the screen isn't updating but the content being displayed is there, correct and straight
[10:15] <ogra_> k, just checking
[10:16] <popey> like we're dropping frames
[10:16] <didrocks> ogra_: let me open an app and seeing
[10:16] <didrocks> popey: yeah, °1
[10:16] <didrocks> +1
[10:16] <popey> davmor2: got a bug filed? If not i'm happy to file one
[10:17] <didrocks> sil2100: keep us posted, the system settings one is the easiest to reproduce and get a feel on the image startup
[10:17] <didrocks> but it's all seem linked
[10:18] <didrocks> ogra_: yeah, nothing weird in syslogs or upstart logs
[10:18] <ogra_> good
[10:18] <Saviq> hey, who apart from fginther can help with a -ci mako testrunner https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/5917/console ?
[10:18] <didrocks> it's an initial "damage" on the apps that is missing IMHO
[10:20] <ogra_> didrocks, so given that 241 looks really good, should we focus on that for possible promotion ?
[10:20] <didrocks> ogra_: hum?
[10:20] <didrocks> ogra_: did you see my list of regressions?
[10:20] <didrocks> on the phone ML?
[10:20] <ogra_> (while debugging 242 and 243)
[10:20]  * ogra_ checks
[10:20] <didrocks> I don't think we should promote before getting those fixes
[10:20] <ogra_> i dont see a mail from this monring
[10:21] <didrocks> ogra_: the one from yesterday
[10:21] <didrocks> ogra_: the issues are not fixed (we discussed in the meeting one by one)
[10:22] <ogra_> hmm, k
[10:22] <sil2100> It's almost flashed
[10:23]  * didrocks hopes in sil2100 to confirm what broke it :)
[10:24]  * ogra_ wonders why 241 shows 6 crashes on the dashboard while there are only the 3 known ones
[10:24] <dbarth> hi
[10:25] <dbarth> sil2100: can i get a silo for line 13; the FFE has been acked, and we'd like to also land the multi-arch fix (just added on the list of MPs)
[10:25] <sil2100> dbarth: excellent, let me see
[10:26] <asac> didrocks: we can still look at jenkins?
[10:26] <asac> :)
[10:26] <Laney> Can I have a silo for line 68 please? It should be a noop for all existing arches - just enabling new ones.
[10:26] <asac> hope so
[10:26] <didrocks> asac: that's exactly what I was typing to psivaa
[10:27] <didrocks> if he can fetch results manually for us then
[10:27] <sil2100> Laney: looking in a moment
[10:27] <Laney> sil2100: ta
[10:27] <psivaa> didrocks: asac: the results will be available once the tests complete but only the instantaneous syncing is not working, which i can do for now :)
[10:27] <sil2100> uuuh, silos are oversaturated!
[10:28] <sil2100> didrocks: on 242 system settings opens up quite fast, like 5 seconds
[10:29] <sil2100> didrocks: by quite fast I mean faster than 243, let me upgrade Mir now
[10:29] <ogra_> "fast" :P
[10:29] <sil2100> ;p
[10:31] <didrocks> psivaa: ah ok
[10:33] <cjwatson> sergiusens: gallery-app has built everywhere now modulo PPA publishing, assuming that's what you were concerned about
[10:33] <sergiusens> yeah, just following up on an email bill sent me
[10:34] <cjwatson> Bill left IRC last night before I could explain the situation properly
[10:34] <cjwatson> I was working on it while he was leaving
[10:34] <cjwatson> It was libmediainfo's fault, and https://launchpad.net/ubuntu/+source/libmediainfo/0.7.67-2ubuntu1 fixed it
[10:35] <sergiusens> from the failing build logs seems that should fix it
[10:36] <sergiusens> in any case; you have boxes for people to use and check their builds, right?
[10:38] <cjwatson> Yes
[10:38] <cjwatson> No need to invoke the failing build logs, https://launchpad.net/~ci-train-ppa-service/+archive/landing-015/+packages is green now
[10:39] <cjohnston> psivaa: what tests aren't being seen
[10:39] <sil2100> didrocks, ogra_, davmor2: upgrading libmirserver17 and a few other Mir packages didn't make the problem appear, hm, will look closely into the package diffs and upgrade some more
[10:40] <sil2100> didrocks: btw. regarding that packaging diff for unity-scope-click, mhr3 told me that all the tests are still ran, just manually as part of make test in the debian/rules
[10:40] <psivaa> cjohnston: the results on image 243, whilst it's running are not seen.
[10:40] <psivaa> cjohnston: we normally see those results whilst the are running. but that bit is not happening
[10:41] <didrocks> sil2100: hum apparmor-easyprof-ubuntu?
[10:41] <mhr3> sil2100, i didn't say all
[10:41] <mhr3> sil2100, they did disable the old vala ones indeed
[10:41] <mhr3> sil2100, the c++ ones run though
[10:43] <sil2100> mhr3: but only the c++ ones are relevant right now, right?
[10:43] <sil2100> didrocks: trying some more, that one as well
[10:43] <mhr3> sil2100, right, the vala scope will be removed as soon as new-scopes are used
[10:44] <didrocks> mhr3: desktop as well?
[10:46] <mhr3> didrocks, click scope was never relevant for desktop
[10:46] <didrocks> ah, it's only on click
[10:46] <ogra_> hmm, on 243 the hud misbeahves for me (hangs when collapsing it) i wonder if thats related
[10:47] <cjohnston> psivaa: I'm not sure.. we will have to wait for doanac`
[10:47] <psivaa> cjohnston: ack, thanks for looking into it
[10:50] <sil2100> didrocks: can I treat this as a +1 for that package? ;)
[10:50] <didrocks> sil2100: yep
[10:50] <sil2100> didrocks: (still downgrading stuff for the settings issue)
[10:52] <sergiusens> cjohnston, what happened yesterday was that the links changed to trigger jobs (they have full paths to the device specific channel); not sure if the dashboard depends on something like that as well
[10:53] <sil2100> didrocks: I don't get it... I upgraded everything from the list here http://people.canonical.com/~ogra/touch-image-stats/20140318.changes (by everything I mean copy-paste everything) and settings still opens up after 4-5 seconds for me
[10:53] <sil2100> ah
[10:53] <sil2100> Wait, I might know what's up
[10:53] <sil2100> didrocks: let me upgrade to 243 and do a 'downgrade'
[10:53] <didrocks> sil2100: oh?
[10:53] <sil2100> didrocks: since I think the reason might be that the system settings app has a notification of an update on it
[10:53] <didrocks> sil2100: wdyt?
[10:54] <didrocks> oh right
[10:54] <didrocks> sil2100: you can fake the version
[10:54] <sil2100> didrocks: and because of that, it forces a 'refresh' after appearing
[10:54] <didrocks> sil2100: it will be easier
[10:54] <sil2100> oh, how?
[10:54] <didrocks> sil2100: I would say edit /etc/system-image/channel.ini
[10:59] <davmor2> Morning all
[10:59] <sil2100> didrocks: ok, so, after 'faking' the version, yes, I can reproduce - so I guess one of the packages I upgraded was at fault ;p
[10:59] <davmor2> popey: did you file one if not I can?
[10:59] <didrocks> :p
[10:59] <sil2100> Too bad I upgraded like, ALL OF THEM
[10:59] <sil2100> geh, I could have noticed this earlier ;)
[10:59] <ogra_> fun
[10:59] <popey> davmor2: no, thats why I asked ☻
[11:00] <davmor2> haha
[11:00] <davmor2> popey: I was checking that you hadn't filed one in the meantime :)
[11:02] <popey> davmor2: nope
[11:02] <sergiusens> didrocks, wrt to changelog generation; is the bootstrapping process documented anywhere?
[11:02] <didrocks> sergiusens: not with CI Train, I asked some LT member, if they have time, to do it
[11:03] <didrocks> sergiusens: basically, it's just "ensuring that bzr bd is working" and "tagging previous release"
[11:03] <sergiusens> didrocks, the stub release was just a test fwiw; not what triggered creating that bug in the first place
[11:03] <didrocks> sergiusens: there was no tag for the previous release
[11:03] <didrocks> sergiusens: and that's something robru knows from the code itself, not sure why he didn't check
[11:04] <didrocks> sil2100: trying to upgrade Mir
[11:04] <didrocks> (with the version hack)
[11:04] <davmor2> popey: I'm assuming unity8 right?  I doubt it's the sensors
[11:05] <popey> davmor2: either unity8 or mir
[11:05] <didrocks> sil2100: davmor2: popey: confirming, it's Mir for the bug
[11:05] <sil2100> didrocks: I tried downgrading stuff now, but I guess you'll be faster then I will be
[11:05] <didrocks> and slowliness of app startup
[11:06] <davmor2> didrocks: \o/
[11:06] <didrocks> popey: davmor2: do you have a bug for this?
[11:06] <sil2100> didrocks: did you check if on 242 with the version hack without mir being upgraded?
[11:06] <didrocks> sil2100: yep
[11:06] <davmor2> didrocks: filing it as we speak
[11:06] <sil2100> didrocks: to check if 242 was free of the bug
[11:06] <sil2100> ACK
[11:06] <didrocks> and then I upgraded it
[11:06] <sil2100> Ok... too bad then that it's mir, but at least we know now
[11:06] <sergiusens> didrocks, the previous release didn't have the expected format; that stub version was something I just added later in the night
[11:06] <sil2100> didrocks: thanks!
[11:07] <didrocks> sergiusens: hum? there is no exceptation on the format, what do you mean?
[11:08] <sergiusens> didrocks, the previous tagged release was 1.12+bzrXXXXX-0ubuntu1 and it is tagged
[11:08] <didrocks> sergiusens: saw the bug report?
[11:08] <sergiusens> didrocks, the version with  1.12.bzr6858+14.04.20140316-0ubuntu1 is something I made up much later in the game
[11:09] <sergiusens> much after the bug report was created
[11:09] <sergiusens> didrocks, yes; that's why I'm bringing this up :-)
[11:09] <didrocks> sergiusens: hum, I will need to have the initial state to see why the tag wasn't picked up then
[11:09] <didrocks> do you have it somewhere?
[11:09] <sergiusens> didrocks, no but I can recreate it
[11:10] <didrocks> sergiusens: yeah, if we can simuate that in a silo, I would be interested
[11:10] <didrocks> simulate*
[11:10] <didrocks> sergiusens: because there is no format or whatsoever expectation, not sure why you created 1.12.bzr6858+14.04.20140316-0ubuntu1
[11:10] <didrocks> probably some miscommunication making people believe that :)
[11:11] <sergiusens> didrocks, because I didn't have a clear answer on how it worked so I was experimenting ;-)
[11:11] <didrocks> sergiusens: yeah, basically, it just bzr tags -> pick the revison and work from it
[11:14] <sergiusens> didrocks, this is the original lp:~sergiusens/ofono/citraintest
[11:14] <sil2100> Laney: ok, so we have too many landings pilled up it seems
[11:14] <didrocks> sergiusens: can you make a MP against it then?
[11:15] <didrocks> sergiusens: to really recreate the situation
[11:15] <sil2100> Laney: there is no free silo - I'm even freeing one to have it as a 'safety net'
[11:15] <sergiusens> didrocks, ok; I'll clear up the target as well
[11:17] <sil2100> Mirv, didrocks: just so you guys know - we have currently all 20 silos assigned, I'm even freeing up the ubuntu-keyboard one for now because it wasn't 'touched' yet and I really would like to have at least one silo free for emergency uses
[11:17] <didrocks> sil2100: hum, IIRC, I repeated multiple times to have at least 4-5 available
[11:17] <didrocks> what happened?
[11:18] <didrocks> why did we assign more?
[11:18] <cjwatson> landing-015 could be poked into noticing that everything is built
[11:18] <davmor2> popey, didrocks: rotate issue https://bugs.launchpad.net/mir/+bug/1294048  , apps slower to open https://bugs.launchpad.net/mir/+bug/1294051  ,  grey screen on settings https://bugs.launchpad.net/mir/+bug/1294053
[11:18] <sil2100> didrocks: I don't know, it was like that when I appeared in the morning
[11:18] <Laney> sil2100: bah
[11:19] <sil2100> didrocks: I thought we had many free, wanted to assign a silo and see uh - assigning silo 20
[11:19] <cjwatson> as could landing-016
[11:19] <didrocks> sergiusens: you have 5 silos
[11:19] <Laney> seb128 has a couple of landings that aren't tested yet ;-)
[11:19] <cjwatson> I suspect several silos were broken by the librarian ENOSPC last night and just need to be prodded
[11:19] <didrocks> sil2100: weird, so you had many frees in the previous assignement? (you have the whole list of free ones when assigning)
[11:19] <seb128> Laney, they finished building like half an hour ago, I'm on it
[11:19] <Laney> excellent!
[11:20] <didrocks> sil2100: some are "silo ready", please flush them maybe
[11:20] <sil2100> didrocks: ok, that's what I did with ubuntu-keyboard just now
[11:20] <sil2100> Will free up more
[11:21] <seb128> I'm going through mines, those should keep moving/be freed soon
[11:21]  * sil2100 freed 2 more silos
[11:22] <sil2100> mhr3: I freed one of your silos as it wasn't moved and we're currently low on silos
[11:22] <sil2100> seb128: I also freed one of your silos for the very same reason ^
[11:22] <mhr3> sil2100, which one?
[11:22] <seb128> sil2100, which one?
[11:22] <sergiusens> didrocks, https://code.launchpad.net/~sergiusens/ofono/citraintest/+merge/211498
[11:23] <sil2100> mhr3: line 26
[11:23] <sergiusens> didrocks, is there an easy way to view them?
[11:23] <didrocks> sergiusens: ok, this is the exact same sate, right?
[11:23] <didrocks> sergiusens: just look at "sergiusens" I guess on the spreadsheet
[11:23] <didrocks> you have 5 :)
[11:23] <sil2100> mhr3: will re-assign once some of the currently built ones are flushed out
[11:23] <seb128> sil2100, which one for me? I didn't have any silo ready to be freed I think
[11:23] <mhr3> sil2100, ok
[11:23] <popey> thanks davmor2
[11:23] <sil2100> seb128: aaarght, sorry!
[11:23] <sil2100> seb128: didn't mean you
[11:24] <sergiusens> didrocks, yes; originally everyone would have preferred to keep the original versioning with the two '+'
[11:24] <sil2100> I meant sergiusens
[11:24] <sil2100> ;)
[11:24] <seb128> sil2100, what did you do?
[11:24] <seb128> sil2100, oh, ok
[11:24] <sil2100> sergiusens: ^
[11:24] <seb128> good ;-)
[11:24] <sergiusens> sil2100, didrocks I have 5 silos but am the lander for like 50 trunks
[11:24] <sergiusens> keep that in mind ;-)
[11:24] <sil2100> sergiusens: I also freed one of your silos for the very same reason ^
[11:24] <sergiusens> mandel, hurry your silo ^^
[11:25] <didrocks> sergiusens: ok, I'm simulating your merge
[11:25] <mandel> sergiusens, well, I have tested it, but I'd like barry to take a look too
[11:25] <mandel> sergiusens, is not that I can bully him to do it, but only because it is to early for him :)
[11:25] <sergiusens> mandel, if he doesn't get to it today; I'm afraid it will be freed up
[11:25] <mandel> sergiusens, ok, I'll make sure of it being done asap
[11:27] <sergiusens> sil2100, didrocks fwiw l20 is free
[11:27] <sergiusens> sil2100, didrocks feel free to release l30/silo 4
[11:28] <sil2100> sergiusens: ACK
[11:28]  * sergiusens wants out from the landing business
[11:29] <sil2100> seb128: checking your landning 014 in a moment
[11:29] <seb128> sil2100, what about it?
[11:29] <seb128> sil2100, I just published it, is there an issue?
[11:30] <didrocks> seb128: ok, reproduced btw
[11:31] <seb128> didrocks, reproduced what?
[11:31] <didrocks> argh
[11:31] <didrocks> sergiusens*
[11:31] <sil2100> seb128: oh, ok, nevermind then - I thought we were required to test eveyrhing ourselves as well
[11:31] <didrocks> se<tab> isn't possible anymore
[11:31] <sil2100> seb128: but I guess we trust you enough ;)
[11:31] <seb128> sil2100, thanks ;-)
[11:32] <sergiusens> didrocks, so it doesn't work?
[11:34] <didrocks> sergiusens: yeah, it's because you have in the destination a version number that will never be released
[11:34] <didrocks> sergiusens: as there were direct push to trunk
[11:34] <didrocks> and the fallback which is to find a "Releasing <previous version>" couldn't work as well
[11:35] <cyphermox> morning!
[11:35] <didrocks> hey cyphermox (it's early for you)
[11:35] <didrocks> sergiusens: I need to find a way to rely on something else I guess
[11:35] <cyphermox> well, it's a reasonable morning hour really
[11:35] <cyphermox> I've been up for four hours already :)
[11:35] <ogra_> didrocks, hmm ? xchat has heiristics for se<tab> to only complete the nick you talked to last
[11:35] <ogra_> *heuristics
[11:36] <ogra_> just use a sane client ;)
[11:36] <sergiusens> didrocks, so what should I do?
[11:36] <didrocks> sergiusens: nothing, keep it like that, I have some ideas how to fix that
[11:37] <sergiusens> didrocks, ok, we can reconfigure silo 007 then to use the MR
[11:37] <psivaa> didrocks: ogra_: so the flashing of image 242 failed soon after 'phablet-flash:Clearing /data and /cache' could the issue have been injected in 241?
[11:38] <ogra_> psivaa, well, to my knowledge you are having your own hacks to phablet-flash
[11:38] <ogra_> sergiusens, ^^^  ?
[11:39] <didrocks> sergiusens: this worked for everyone who didn't push to trunck directly while changing the changelog version :p
[11:39] <didrocks> or had a previous release of CI Train/Daily release as it's the fallback
[11:39] <sergiusens> psivaa, ogra_ only reason for that to fail is to have been disconnected
[11:39] <psivaa> ogra_: afaik, that is not in the way of flashing. 243 is being flashed in the same way
[11:40] <psivaa> sergiusens: but all the 3 devices got disconnected after clearing the /data and /cache step
[11:40] <sergiusens> didrocks, I know; rsalveti wanted this to start using the train to get the other arches built for for testing
[11:40] <sergiusens> psivaa, oh; then no
[11:41] <psivaa> sergiusens: and they dint happen at the same time for me to suspect any activity on the server side
[11:42] <Mirv> sil2100: that was probably me, although I think we were quite full before I assigned 3 more
[11:42] <Mirv> (in the morning)
[11:42] <davmor2> didrocks: so the phone works but I really, really wouldn't promote it till those issues with mir are resolved.
[11:42] <sergiusens> psivaa, anyways if there's anything needed in phablet-tools; you are sort of blocked as the infra is on raring
[11:43] <didrocks> davmor2: yeah, no new regression to mention at least?
[11:44] <psivaa> sergiusens: yea, we are moving to saucy this weekend
[11:44] <davmor2> didrocks: no same faults as in yesterdays tested image just with the slowness and quirkiness added in for good measure :)
[11:44] <sergiusens> psivaa, not sure how it failed; where is this log?
[11:45] <psivaa> sergiusens: http://q-jenkins.ubuntu-ci:8080/job/trusty-touch-mako-smoke-daily/158/console
[11:45] <sil2100> Mirv: let's just remember about leaving like 3-4 silos free ;) The number of assigned silos can be seen either by looking at the peoples backend or the metadata sheet
[11:45] <davmor2> didrocks: well there are the mir regressions of course :)
[11:46] <Mirv> sil2100: ok. remember I'm actually relatively "new" to CI Train now that I have that monster of Qt 5.2 mostly behind me... sorry about that.
[11:46] <didrocks> davmor2: yep
[11:46] <didrocks> sergiusens: hum, so I have a quick fix for your case, but potentially, it will create other issues to other cases, thinking about it
[11:47] <didrocks> sergiusens: like releasing something else
[11:47] <didrocks> the issue is really that trunk have an UNRELEASED changelog change
[11:47] <sil2100> Mirv: no problem! Nothing bad really happened, it's anyway just a safety bubble ;)
[11:47] <didrocks> hum
[11:48] <didrocks> we can do a 3 way falling down
[11:48] <sergiusens> didrocks, ok; so my best bet is to rewrite the target branch to only have the latest released and bring that into the MR?
[11:48] <didrocks> sergiusens: no, I'll try to handle this case
[11:48] <sergiusens> ah, ok
[11:48] <didrocks> sergiusens: I have an idea, it might duplicate some lines, but not everything
[11:48] <didrocks> at least, not 100 commits
[11:50] <sergiusens> psivaa, ogra_ right above that error you gave me I see 'error: device not found'
[11:50] <sergiusens> psivaa, ogra_ it's not a phablet-flash problem it seems
[11:50] <ogra_> right
[11:51] <sil2100> didrocks: huuum, I'm not up-to-date with the CI smoketesting infra stuff, but what happened to 242 test results?
[11:51] <ogra_> (thats what i pointed out a few hours ago already)
[11:51] <sil2100> Ah, wait
[11:51] <psivaa> sergiusens: ogra_: but that's right after the clear commands from phablet-flash.. on all 3 devices
[11:51] <sil2100> Right
[11:51] <ogra_> (i thought psivaa had found something new)
[11:51] <sil2100> didrocks: nevermind!
[11:51]  * sil2100 mixed up version numbers
[11:51] <sil2100> We only had for 241 before anyway
[11:52] <sergiusens> psivaa, ogra_ my best bet is that you lost your udev rules to run adb commands against a root adb
[11:52] <ogra_> on the server ?
[11:52] <ogra_> hmm
[11:52] <sergiusens> psivaa, reboot into recovery and see if you can run adb commands
[11:52] <ogra_> why would thy vanish while the machine is running
[11:53] <sergiusens> ogra_, because it rebooted into recovery
[11:53] <psivaa> sergiusens: the devices have flashed successfully with 243 on the same server
[11:53] <sergiusens> ogra_, when you reboot into recovery; the device IDs change
[11:53] <ogra_> oh, right
[11:53] <psivaa> sergiusens: not the same devices though
[11:53] <ogra_> but there were no changes for ages
[11:54] <sergiusens> psivaa, with no access to the server or a changelist there I can't really know
[11:54] <ogra_> is the code cleaning cache and data new ?
[11:54] <sergiusens> psivaa, can you try flashing 241 again with --revision 241?
[11:54] <sergiusens> ogra_, no; phablet-flash hasn't changed for 4 months iirc
[11:54] <ogra_> sergiusens, i mean on the server :)
[11:55] <ogra_> i know they applied manual changes yesterday for the channel change
[11:55] <sergiusens> ogra_, that's phablet-flash at work
[11:55] <didrocks> sergiusens: didrocks@tidus:~/work/cupstream2distro/trunk
[11:55] <didrocks> argh
[11:55] <didrocks> sergiusens: http://paste.ubuntu.com/7113642/
[11:55] <sergiusens> ogra_, yeah, it shouldn't be related to that
[11:55] <didrocks> better?
[11:55] <sergiusens> didrocks, well that's exactly what we want :-) so of course ;-)
[11:56] <didrocks> sergiusens: deploying from preprod to prod
[11:56] <didrocks> sergiusens: done!
[11:56] <sergiusens> didrocks, let me reconfigure that silo now
[11:59] <sergiusens> didrocks, is this common btw?ERROR:root:ofono is already prepared for the same serie and destination in landing-000
[11:59] <sergiusens> I get that here: http://162.213.34.102/job/landing-007-0-reconfigure/12/console
[12:00] <sil2100> seb128: you can merge and clean some of your landings :)
[12:01] <sil2100> mhr3: merge and clean your landing for click scope!
[12:01] <didrocks> sergiusens: yeah, it's a real error when you don't reconfigure
[12:01] <sergiusens> didrocks, but that's what I just did
[12:01] <didrocks> sergiusens: basically it means 2 silos are using the same components, which isn't available by default
[12:01] <didrocks> and landing-000 was what I was testing :)
[12:02] <sergiusens> oh...
[12:02] <sergiusens> ok
[12:02] <sergiusens> so when you free that up; I'll reconfigure ;-)
[12:02] <didrocks> sergiusens: I should in the "reconfigure" case, downgrade the error to a warning in the ouput
[12:02] <seb128> sil2100, thanks for watching but no need to watch my stuff, I'm usually pretty good at getting them moving, I published before going to eat, just back
[12:02]  * sil2100 shouldn't inform about that but we have a silo shortage ;)
[12:02] <didrocks> sergiusens: oh no worry, all was fine
[12:02]  * sergiusens builds
[12:02] <didrocks> sergiusens: only when we assign, it's a blocking error (and the job fails in that case)
[12:03] <sergiusens> ok, makes sense; the 000 seemed like a problem
[12:03] <sergiusens> but I guess it's your hidden test lab :-P
[12:04] <didrocks> sergiusens: exactly :p
[12:04] <didrocks> sergiusens: using the preproduction code
[12:04] <didrocks> (so only on request)
[12:04] <seb128> didrocks, sil2100: is there a summary of the silos available somewhere? looking to the list it seems like there should be at least 6 available now
[12:04] <seb128> rather closer from 8
[12:04] <sil2100> seb128: now it's fine
[12:05] <sil2100> seb128: I usually use this: http://people.canonical.com/~platform/citrain/
[12:05] <seb128> sil2100, so stop pinging 5 minutes after stuff get ready :p
[12:05] <sil2100> seb128: hey hey, it was just temporary, wanted to buffer up stuff since I have some silos to assign ;)
[12:05] <seb128> k, cool, you have them now ;-)
[12:05]  * seb128 goes to add some more requests to the list
[12:06] <sil2100> There are 4 silos free right now, and I want to keep having 3 silos free all the time
[12:06] <sil2100> Since that's the theoretical buffer we want to have
[12:07] <seb128> right, 3 silos are being cleaned
[12:07] <seb128> so you are going to have some spare room soon
[12:07] <sil2100> Thanks!
[12:08] <Mirv> seb128: whee, thanks. I assigned yours in the morning but should have waited a bit.
[12:09] <seb128> Mirv, well, early assignement is fine, if you don't want to lock for nothing you can start the builds though ;-)
[12:09] <seb128> so when I start I've builds results to test
[12:09] <seb128> which reduce the turnaround
[12:10] <didrocks> sergiusens: ok, it will only show it as a warning if you reconfigure a silo having the conflict (as it is in that case a warning only)
[12:30] <Mirv> sil2100: didrocks: ok AP testing good on the qtbase + 3 testers tested manually the text rendering, so I'll be releasing it
[12:30] <didrocks> Mirv: excellent, one less!
[12:30] <Mirv> sil2100: didrocks: meanwhile, because there's a lack of image test results, it's notable that I only had failures in music-app - not in calendar app or unity8
[12:32] <didrocks> ok
[12:33] <renato_> didrocks, hi, yesterday my Mr (https://code.launchpad.net/~renatofilho/address-book-service/create-source/+merge/206832) get block due a tests failing on powerpc. I did some fixes how I can test it? I tried a powerpc chroot but it crashes when I try to run cmake command
[12:36] <didrocks> renato_: one of the cheapest way is to ask the lander (seems it's boiko), to rebuild address-book-service in the landing silo
[12:36] <didrocks> renato_: oh, are you sure it didn't build?
[12:36] <didrocks> renato_: ah, your branch already landed btw
[12:36] <didrocks> it's just that boiko didn't merge and clean
[12:37] <renato_> didrocks, humm ok I will talk with boiko, thanks
[12:38] <didrocks> hum, the check migration job isn't running anymore
[12:39] <didrocks> renato_: ah no, it's blocked on proposed for other reasons
[12:39] <didrocks> address-book-app/powerpc unsatisfiable Depends: qtcontact5-galera
[12:40] <didrocks> renato_: I misread address-book-app, address-book-service
[12:40] <didrocks> renato_: so you can say him to rebiuld address-book-service from the same silo and try to reland that
[12:40] <didrocks> (with your new merge)
[12:40] <renato_> ok thanks
[12:40] <didrocks> yw ;)
[12:42] <alan_g> cjohnston: we're seeing CI failures, but can't work out from the logs why libmirserver16 is installing can you help? https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/788/console
[12:43] <cjohnston> alan_g: looking
[12:45] <cjohnston> alan_g: is this for an MP or something?
[12:45] <Mirv> didrocks: sil2100: what's "reconfiguresil"? :) http://162.213.34.102/job/prepare-silo/556/console
[12:45] <alan_g> cjohnston: All the MPs are failing this way
[12:45] <didrocks> Mirv: a o is missing
[12:45] <Mirv> I guess typo in a recent deployment, and should be silo?
[12:45] <didrocks> Mirv: with the prod I did
[12:45] <Mirv> didrocks: right o
[12:45] <didrocks> yeah
[12:45] <didrocks> let me fix it, one sec
[12:45] <cjohnston> alan_g: could I get a link to one please
[12:46]  * didrocks wonders why pyflake didn't yell
[12:46] <alan_g> cjohnston: https://code.launchpad.net/~vanvugt/mir/version-0.1.8/+merge/211249
[12:46] <cjohnston> ta
[12:47] <didrocks> Mirv: done and deployed on preprod and prod
[12:48] <Mirv> didrocks: looking good! thank you.
[12:48] <cjohnston> alan_g: not sure if its related but are you aware of whats going on http://people.canonical.com/~ubuntu-archive/testing/trusty_probs.html
[12:49]  * alan_g looks
[12:52] <alan_g> cjohnston: well, I'd seen https://code.launchpad.net/~cjwatson/mir/stdint-include/+merge/211340 if that's what you mean by "aware"
[12:52] <Mirv> Laney: landing-001 assigned to your qtbase change and I uploaded it there already. armhf expected build time a jolly 3.5h - https://launchpad.net/~ci-train-ppa-service/+archive/landing-001/+packages
[12:53] <cjohnston> alan_g: ack.. still looking
[12:54] <Laney> Mirv: sweet, thanks
[12:58] <sil2100> o_O
[13:07] <psivaa> didrocks: The dashboard now has the results for 243 on mako and manta.. flo is yet to finish
[13:07] <didrocks> psivaa: yeah, saw that. Thanks for the head's up
[13:07] <psivaa> sergiusens: ogra_: so i flashed 241 and 242 on another device in the lab and that flashed ok..
[13:08] <psivaa> sergiusens: ogra_: something must have happened on the server side as you said at that time interval, which i am looking at now. and sorry for the noise :)
[13:09] <ogra_> np
[13:09] <sergiusens> psivaa, this makes me think something was going on at the server during these flashes
[13:09] <sergiusens> psivaa, no worries
[13:09] <ogra_> good that you could exclude the images themselves
[13:10] <sergiusens> psivaa, it wouldn't be a surprise to me to know that someone tripped over a cable either ;-)
[13:11] <ogra_> lol
[13:11] <psivaa> ogra_: sergiusens: was too late in night for anyone to be awake :)
[13:11] <ogra_> these are toe worst ones ... sleepwalking people tripping over cables !
[13:11] <ogra_> *the
[13:12] <psivaa> toe would suite as well :)
[13:26] <didrocks> ok, I need to go for a run
[13:26] <didrocks> sil2100: cyphermox: can you let kgunn knows about the issues with the Mir landing if he shows off before?
[13:27] <didrocks> https://bugs.launchpad.net/mir/+bug/1294051
[13:27] <didrocks> https://bugs.launchpad.net/mir/+bug/1294053
[13:27] <didrocks> https://bugs.launchpad.net/mir/+bug/1294048
[13:27] <didrocks> we can't revert, so he needs to fix that ASAP
[13:28] <bzoltan1> asac: ping
[13:28] <didrocks> also, tests in their QA process needs to be added (manually or automatically)
[13:32] <cjwatson> cjohnston,alan_g|lunch: arm64 aside, that actually looks like an override bug.  checking
[13:33] <sil2100> didrocks: ok
[13:33] <cjwatson> cjohnston,alan_g|lunch: yep - I've moved libmirserver17 from universe to main, that should help
[13:33] <sil2100> didrocks: so for now we're not reverting because it's troublesome and give them some time to get it fixed ASAP?
[13:34] <didrocks> sil2100: because of ABI break leading to package rename, reverting can bring more issues
[13:34] <cjwatson> Mirv: /wg 23
[13:34] <cjwatson> Mirv: sigh, sorry
[13:34] <didrocks> or we need to add another binary package
[13:35] <sil2100> Righto
[13:35] <cjohnston> cjwatson: ack
[13:35] <didrocks> sil2100: so, they took the risk, I told I wasn't thrilled, now it's time for them to take responsibility for their decisions and shine
[13:35] <sil2100> didrocks: let's wait for their sunrise then!
[13:36] <didrocks> heh
[13:37] <Mirv> wg, wg
[13:39] <bfiller> didrocks: silo-15 is failing to buid on some arches (arm64, powerpc, pp64el) and it's blocking the landing. Are these required now to be able to land something?
[13:39] <didrocks> bfiller: they only block normally if they built previously in the release pocket successfully
[13:39] <didrocks> hey btw
[13:40] <sergiusens> bfiller, fwiw gallery was fixed by cjwatson
[13:40] <bfiller> didrocks: hmn, ok
[13:40] <bfiller> sergiusens: oh cool, I see that now. thanks cjwatson
[13:41] <didrocks> bfiller: btw, any update on messaging-app flaky test failure?
[13:42] <bfiller> didrocks: the sheet still says the build failed though, do I need to rebuild?
[13:42] <didrocks> bfiller: just rebuild with "watch only", I guess you built during the launchpad outage and the source package wasn't published
[13:42] <bfiller> didrocks: the guys looked at it yesterday for quite some time and do not yet have a solution
[13:43] <didrocks> bfiller: ok, please if you have any info, update on the ML
[13:43] <bfiller> didrocks: will continue to look at it and could use some help from elopio
[13:43] <didrocks> thanks
[13:43] <didrocks> bfiller: so yeah, watch only (if there is no new commits in)
[13:43] <bfiller> didrocks: got it, thanks
[13:43] <cjwatson> bfiller: it was a libmediainfo bug
[13:44] <didrocks> cjwatson: arm64 is still stuck
[13:44] <cjwatson> didrocks: uh, it wasn't last I looked
[13:44]  * didrocks opens update-excuse
[13:44] <didrocks> cjwatson: I just rmadison
[13:44] <didrocks> cjwatson: did you just fixed it? maybe arm64 didn't publish yet
[13:45] <cjwatson> didrocks: I fixed it last night
[13:45] <didrocks>  gallery-app | 0.0.67+14.04.20140307-0ubuntu1   | trusty-proposed/universe | arm64
[13:45] <cjwatson> gallery-app/arm64 is in both trusty and trusty-proposed
[13:45] <didrocks> oh right
[13:45] <Mirv> didrocks: rsalveti: qtbase 5.2.1+dfsg-1ubuntu9 now in release pocket, probably time for image build
[13:45] <cjwatson> no idea why, I expect it'll clear itself up
[13:45] <rsalveti> Mirv: great
[13:45] <didrocks> cjwatson: ok then
[13:45] <cjwatson> not a problem, anyway
[13:46] <t1mp> I'm getting weird failures in jenkins CI - https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/5926/console
[13:46] <didrocks> rsalveti: letting you starting it?
[13:46] <rsalveti> alright, starting it now
[13:46]  * didrocks really goes for a run now :)
[13:46] <t1mp> ^ apparently the result of devices not being clean (leftovers of packages that are not merged yet)
[13:46] <cjwatson> didrocks: actually maybe not, I'll remove it from -proposed by hand
[13:46] <t1mp> who can I ask to clean the devices? Or can this be done automatically?
[13:46] <cjwatson> didrocks: might have been due to it being copied from citrain before the arm64 build finished (that was actually this morning, when I retried everything)
[13:46] <didrocks> cjwatson: ok, maybe it was during the outage and something isn't completely transactional…
[13:47] <cjwatson> didrocks: oh, landing-015 hasn't actually landed
[13:47] <cjwatson> that gallery-app 0.0.67+14.04.20140307-0ubuntu1 is from some time back
[13:47] <didrocks> cjwatson: yeah, it's not the new one (and there is only one copy from CI Train)
[13:47] <cjwatson> so when landing-015 is landed, it should clear this up
[13:47] <cjwatson> bfiller: ^-
[13:47] <didrocks> ok ;)
[13:48] <Saviq> didrocks, so, manta failures: there's no bluetooth indicator on manta, should there be?
[13:48] <didrocks> bfiller: packages built btw
[13:48] <cyphermox> Saviq: most likely yes
[13:48] <didrocks> Saviq: ogra_ looked at that IIRC (I don't have manta and unsure but I guess it should have bluetooth)
[13:49] <cjwatson> bfiller: you might want to prod landing-016 too - citrain tried to upload it during the LP outage and got confused when it took too long to be processed, but it's in the actual PPA
[13:49] <Saviq> so yeah, if it should - it doesn't
[13:49] <bfiller> didrocks, cjwatson : thank you
[13:49] <ogra_> Saviq, cyphermox needs to make it work ... BT isnt available at all on manta atm :=
[13:49] <bfiller> cjwatson: looking
[13:49] <cyphermox> gah
[13:49] <Saviq> ok /me needs to skip that test on manta
[13:49] <ogra_> Saviq, i guess we need to send him a manta ... i tried my best to get it up here
[13:49] <imgbot> [13:49] <ogra_> but no dice
[13:49] <cjwatson> I don't know exactly what citrain needs to become less confused there
[13:50] <Saviq> ogra_, ok thanks, clears one thing up
[13:50] <ogra_> Saviq, we should skip such tests on devices where they cant be run
[13:50] <ogra_> oh, you said that already
[13:50] <Saviq> ogra_, yeah, of course, just I never knew that :)
[13:50] <ogra_> i fixed it on flo ... but manta didnt like to cooperate
[13:51] <Saviq> ogra_, is there a bug maybe?
[13:51] <cyphermox> ogra_: what's the device like on the manta?
[13:51] <ogra_> cyphermox, some samsung chipset
[13:51] <cyphermox> oh cool
[13:51] <ogra_> havent found out which exactly
[13:51] <cyphermox> that one might actually not be retarded
[13:51] <ogra_> not broadcom
[13:52] <cyphermox> manta is nexus 5?
[13:52]  * cyphermox looks to acquire one
[13:52] <didrocks> cjwatson: actually, I'm waiting for 20 minutes
[13:52] <sil2100> I thought nexus 5 was manta
[13:52] <didrocks> cjwatson: and then, give up (to not have stalled build job, as it's not a daemon)
[13:52] <sil2100> I mean
[13:52] <sil2100> No, nexus 10 was manta
[13:52] <didrocks> cjwatson: this was more relevant for daily-release than CI Train though
[13:53] <sil2100> Nexus 5 is flo, right?
[13:53] <Saviq> sil2100, Nexus 7 is flo
[13:53] <Saviq> sil2100, we don't support Nexus 5
[13:53] <didrocks> not sure, it needs to surface on the UI that "nothing showed up on the ppa, you should have a look"
[13:53] <sil2100> Saviq: ah, right
[13:53] <sil2100> Saviq: but manta was 10, right?
[13:53] <didrocks> (which is why it's failing)
[13:53] <Saviq> sil2100, yes
[13:54] <Laney> sil2100: can I have a u-s-s silo now please? ;-)
[13:55] <cjwatson> didrocks: sure, I'm not saying your current check is wrong
[13:55] <sil2100> Laney: ah, righto! Let me do that ;)
[13:55] <cjwatson> didrocks: just that the silo needs to be deconfused in this particular case
[13:55] <Saviq> cjohnston, hey, apparently phablet-flash got deprecated, so the flash jobs in -ci don't do nothing any mroe
[13:55] <Saviq> more
[13:55] <Saviq> cjohnston, which results in "dirty" devices in test runs
[13:55] <cjohnston> Saviq: yup
[13:55] <didrocks> cjwatson: ah, FYI, it's quite easy, if there is nothing to rebuild, run the build job with "watch only" which only look at the current state and scan ppa (and eventually wait for what remains to be built)
[13:55] <cjwatson> didrocks: (this sort of situation should be exceptional)
[13:56] <Saviq> cjohnston, is there something we could do to fix this?
[13:56] <cjwatson> didrocks: ah right
[13:56] <cjwatson> bfiller: ^- I'll do that for you then
[13:56] <cjohnston> Saviq: I'm working on it
[13:56] <alan_g> cjohnston: what's the best way to verify? Reschedule an MP?
[13:56] <cjwatson> bfiller: oh, somebody already did :)
[13:56] <Saviq> cjohnston, oh great, thanks
[13:56] <t1mp> Saviq: there is an e-mail about it, see [Ubuntu-phone] phablet-flash deprecated reminder
[13:56] <Saviq> t1mp, ↑
[13:56] <t1mp> cjwatson: ^
[13:56] <Saviq> t1mp, wrong cj
[13:56] <sil2100> Laney: hmmm, actually
[13:56] <bfiller> cjwatson: I did it
[13:56] <t1mp> hehe :)
[13:57]  * Saviq would hate it if my IRC client did autocompletion like that
[13:57] <cjohnston> alan_g: I'll ping you when I'm done
[13:57] <asac> bzoltan1: whats up?'
[13:57]  * didrocks really really exercising now :)
[13:57] <t1mp> Saviq: I'm stuck in the past's "client of the future" (irssi)
[13:59] <bzoltan1> asac: good news... you might now some of it. The #1285184 is fixed and on its way to land. The #1288876 is cornered and the fix will come tomorrow.
[13:59] <asac> bzoltan1: amazing. is the train open for this?
[13:59] <asac> didrocks: ?
[14:00] <sergiusens> Saviq, xchat's autocomplete sucks and these past days of everyone going crazy has proven that :-P
[14:00] <bzoltan1> asac: the #1285184  is handled by Mirv
[14:00] <didrocks> asac: it's in the building image already
[14:00] <Mirv> bzoltan1: asac: it was landed via CI Train already
[14:00] <Saviq> sergiusens, I'm in xchat-gnome, and it will only autocomplete when unambiguous, works for me
[14:00] <Saviq> i.e. shell behaviour
[14:01] <bzoltan1> asac:  this Mirv guy is just awsome
[14:01] <asac> ack :)
[14:01] <sil2100> ;)
[14:01] <bzoltan1> asac:  the #1285184 was solved by loicm and timp and by the upstream.
[14:02] <sil2100> Laney: so, the problem with that landing is that it's already part of an existing silo ;)
[14:02] <sil2100> Laney: which is strange!
[14:02] <Saviq> didrocks, so, the other manta fail is reproducible, need to dig in, and the last one is common between the three (the tmp app), and that's still not reproducible locally...
[14:02] <Laney> sil2100: umm which one?
[14:02] <cjwatson> boiko: any progress on address-book-service/powerpc, or am I going to need to apply some kind of brute force to proposed-migration?
[14:02] <sil2100> Laney: landing-020
[14:02] <sil2100> Laney: strange, because it seems to be some unrelated landing?
[14:03] <boiko> cjwatson: renato is working on trying to fix the issues, he has requested access to the porter boxes
[14:03] <boiko> cjwatson: but will only get access in half an hour or so
[14:03] <Laney> sil2100: yes, wtf
[14:04] <Laney> dbarth: what's that about?
[14:04] <cjwatson> boiko: ah, right, it's just waiting for userdir-ldap propagation
[14:05] <t1mp> Mirv: wow. "Fix Released". Does that mean that there is a new image where the font rendering is fixed?
[14:05] <boiko> cjwatson: so, hopefully we will get that sorted out soon
[14:05] <Mirv> t1mp: image building, #244 will be it
[14:05] <cjwatson> boiko: well, I *can* apply force if need be; I prefer not to because with the way proposed-migration works it would loosen its constraints and allow it to make more bad decisions, possibly, but it's possible
[14:05] <t1mp> Mirv: awesome :)
[14:06] <sil2100> t1mp: Fix Released means that the fix is in the archive ;)
[14:06] <cjwatson> so let me know
[14:06] <t1mp> sil2100: thanks. does that always mean that it will be in the next image?
[14:06] <boiko> cjwatson: we still have the possibility of disabling the failing tests if nothing else works
[14:06] <elopio> bfiller: I'm here. Do you need help with the messaging app?
[14:06] <sil2100> t1mp: basically yes
[14:07] <bfiller> elopio: yes please
[14:07] <cjwatson> boiko: ew, but yes :)
[14:11] <bfiller> elopio: we need help figuring out the intermittent issue with messaging-app test (the one where sleep was added)
[14:11] <elopio> bfiller: the only error I see on the latest mako run is on settle after: http://ci.ubuntu.com/smokeng/trusty/touch/mako/243:20140318:20140304/7236/messaging_app/
[14:11] <elopio> bfiller: ah, ok, but the test is passing?
[14:12] <bfiller> elopio: it is passing now, but didrocks concerned because it failed on Friday after your fix was in
[14:12] <bfiller> elopio: but not failing currently, so don't really know where we stand, might still be a race
[14:12] <elopio> ok, let me check that run.
[14:14] <elopio> bfiller: ok, I see it. Here I suspect that the problem is that sometimes autopilot is too fast and gets the element before the sorting proxy is applied. Then, the list is sorted, and autopilot has a reference to a stale object.
[14:14] <elopio> but I don't know enough QML to confirm that, or make a proper workaround.
[14:14] <elopio> bfiller: can one of the messaging devs help me here?
[14:15] <bfiller> elopio: yes, boiko or tiago can help you if you point them in right direction
[14:16] <elopio> ok, going to app-devel to talk with them.
[14:16] <sil2100> psivaa: piing ;)
[14:16] <boiko> elopio: I'm heading for lunch now, but after I'm back I can work with you on that, does that work for you?
[14:17] <elopio> boiko: that's perfect. I have a meeting in 1.5 hours, but I'm mostly available for this any other time. Please ping me when you are back.
[14:17] <psivaa> sil2100: poong :)
[14:17] <boiko> elopio: great! thanks
[14:18] <sil2100> psivaa: hi! Do you know if we have a free CI mako to run a modified unity8 test ;p? And if you have a moment to run it?
[14:19] <psivaa> sil2100: yea, give me the changes
[14:20] <elopio> bfiller: can you please mark this bug as confirmed instead of fix released?
[14:20] <elopio> I don't have permission.
[14:20] <stgraber> just added click to the landing spreadsheet, would be nice if someone could get me a silo
[14:20] <bfiller> elopio: what's bug number?
[14:20] <sil2100> psivaa: http://paste.ubuntu.com/7114291/ <- a new test_url_dispatcher.py
[14:20] <sil2100> psivaa: we would also need to install python-dbus on the device
[14:20] <elopio> bfiller: https://bugs.launchpad.net/messaging-app/+bug/1291394
[14:20] <sil2100> (if not installed before)
[14:21] <sil2100> stgraber: looking
[14:21] <bfiller> elopio: done
[14:23] <sil2100> stgraber: silo 008 assigned
[14:23] <sil2100> psivaa: thanks!
[14:23] <psivaa> sil2100: python-dbus(1.2.0-2build1) is installed. let me do the run
[14:24] <sil2100> o/
[14:24] <elopio> sil2100: the weird error with the url dispatcher test in unity disappeared, right?
[14:24] <elopio> can I abandon this branch?: https://code.launchpad.net/~elopio/unity8/alternate_focused_window/+merge/210956
[14:24] <sil2100> elopio: no no
[14:24] <sil2100> elopio: please leave it, this very instance I asked psivaa to run it on our CI infra
[14:25] <sil2100> elopio: sadly, the error is back :( Which is strange, as when running it earlier on the CI infra the refactoring seemed to fix the test failure
[14:25] <sil2100> elopio: but on the latest images we noticed it appearing again
[14:25] <elopio> sil2100: should I merge it with trunk?
[14:26] <elopio> albert sait it's now not a clean merge.
[14:26] <sil2100> elopio: you can, but for now I'm simply using the test_url_dispatcher.py from your branch instead
[14:26] <elopio> *said
[14:26] <elopio> sil2100: ok. Let me know the results.
[14:26] <stgraber> sil2100: thanks
[14:26] <sil2100> elopio: sure
[14:27] <sil2100> kgunn: hi!
[14:27] <kgunn> morning
[14:27] <sil2100> kgunn: so, we seem to be having some serious problems with the mir that landed recently
[14:27] <sil2100> kgunn: it caused 3 regressions which we need fixed ASAP
[14:28] <kgunn> sil2100: what are they ?the testing i did yesterday went very well
[14:28] <sil2100> kgunn: bugs -> https://bugs.launchpad.net/mir/+bug/1294051 https://bugs.launchpad.net/mir/+bug/1294053 https://bugs.launchpad.net/mir/+bug/1294048
[14:29] <sil2100> kgunn: we confirmed in the morning that reverting the mir bits helps
[14:30] <kgunn> ok...we'll get on it...how long do i have before we revert ?
[14:30] <sil2100> kgunn: it will be very hard to revert due to the package-rename and ABI break
[14:31] <sil2100> kgunn: so we would really prefer just fixing it, as a revert might cause more harm
[14:31] <kgunn> sil2100: ack
[14:31] <kgunn> sil2100: also...those are all qualitative in nature i see
[14:31] <kgunn> e.g. we haven't broken funcationality
[14:32] <sil2100> Right, but most of them are visible - like the 1294053 <- this is very very visible to the user
[14:33] <sil2100> As in the normal case you need to wait for system-settings for ages if you don't click on the screen
[14:41] <bfiller> sil2100, didrocks : can we have a silo for line 28 please?
[14:43] <dbarth> Laney: you blocked on a silo?
[14:43] <dbarth> Laney: or rather, are we blocking you for something else?
[14:43] <sil2100> bfiller: looking
[14:43] <cjohnston> Saviq: the jobs should be fixed
[14:43] <Saviq> cjohnston, awesome, thanks
[14:43] <Saviq> t1mp, ↑
[14:44] <t1mp> cjohnston: great, thanks.
[14:44] <t1mp> cjohnston: are you using ubuntu-device-flash now?
[14:44] <cjohnston> t1mp: nope
[14:45] <cjohnston> we are still on raring.. scheduled to be updated Friday
[14:45] <cjohnston> didrocks: when is the next image going to be built?
[14:48] <sil2100> bfiller: I cannot assign a silo for you because some of those components are already locked (like system settings, webapps-qml, address book and gallery)
[14:50] <bfiller> sil2100: ok
[14:59] <imgbot> [15:06] <sil2100> elopio: hi
[15:06] <sil2100> elopio: sooooo...
[15:07] <elopio> sil2100: this sounds like an introduction to good news.
[15:07] <sil2100> elopio: after running all unity8 tests with the change from your branch, we still seem to get the failure
[15:07] <sil2100> elopio: sadly not ;) Anyway, psivaa gave me this output from the test: http://pastebin.ubuntu.com/7114407/
[15:07] <Laney> dbarth: yes, the system-settings one you included is ready to go separately
[15:07] <Laney> not sure why it's included there, seems a bit random
[15:08] <psivaa> sil2100: elopio: http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-daily/24/ is the full unity8 results
[15:08] <elopio> psivaa: sil2100: right, my branch changes nothing on test_swipe_out_application_started_by_url_dispatcher
[15:08] <elopio> it adds a new test to gather more information.
[15:08] <sil2100> Ah, right! Forgot that
[15:09]  * sil2100 thought that was that test
[15:09] <dbarth> Laney: the multi-arch fix?
[15:09] <sil2100> Let me check on q-jenkins then ;)
[15:09] <elopio> sil2100, psivaa: and both of them fail!
[15:09] <Laney> dbarth: yes
[15:09] <dbarth> Laney: i had a silo ready, so i thought it would be good to go
[15:09] <sil2100> elopio: oh, but it seems the window is not opened!
[15:09] <elopio> that's good for autopilot. Bad for us that still need to understand what's going on.
[15:09] <dbarth> Laney: unless you want to test it with something else, you can drop the MP from your silo; we're just rebuilding to test / land here
[15:09] <sil2100> elopio: which is something new, as I thought that it is but autopilot doesn't find it
[15:10] <dbarth> Laney: the silo was on hold for ~2 weeks
[15:10] <elopio> sil2100: it could be that url-dispatcher didn't open the window, or it could be that unity doesn't report it as opened.
[15:10] <sil2100> elopio: the most puzzling thing is that when the failure started happening there was no change in url-dispatcher actually
[15:10] <sil2100> elopio: indeed
[15:10] <Laney> dbarth: not really, but we could have had it in a while ago, not sure why you decided to claim a system-settings MP like that
[15:10] <elopio> sil2100: any chance of watching what's going on on the screen while the test is running?
[15:11] <sil2100> elopio: not sure if we have the means to do that :( psivaa ^ ?
[15:11] <elopio> sh: 1: url-dispatcher: not found
[15:11] <elopio> sil2100: ^
[15:11] <sil2100> hmmm
[15:11] <elopio> url-dispatcher tools is not installed.
[15:12] <sil2100> elopio: where do you see this?
[15:12] <elopio> http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-daily/24/consoleFull
[15:12] <sil2100> elopio: ok, this would actually answer why it fails! Good catch!
[15:13] <sil2100> elopio: didn't see it, it's not in the final test result on CI and I didn't browse through the big console log it seems!
[15:13] <sil2100> AH!
[15:13] <elopio> sil2100: it is a depencency on unity8-autopilot.
[15:14] <elopio> don't we install that package?
[15:14] <dbarth> Laney: colin recently pinged me about it, so i thought i should land it quickly; no particular reason
[15:14] <sil2100> This would explain why it suddenly worked once when I asked psivaa to run it, maybe some other test suite installed it?
[15:14] <psivaa> sil2100: elopio: http://pastebin.ubuntu.com/7114564/ is the one that's in the device
[15:15] <sil2100> So I wonder why it cannot find it
[15:15] <elopio> psivaa: it's not url-dispatcher, it's url-dispatcher-tools
[15:15] <psivaa> elopio: ok, that's not installed in this device
[15:16] <sil2100> oh, so it's url-dispatcher-tools?
[15:17] <elopio> http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/debian/control#L123
[15:17] <psivaa> elopio: sil2100: i've installed that manually and running the tests now
[15:17] <elopio> yes, I thought adding it to the debian/control would do the trick.
[15:19] <sil2100> I would think that it's enough as well - psivaa do you know how the dependent packages for given tests are resolved?
[15:22] <psivaa> sil2100: i guess we need to specify in http://goo.gl/d9E7ut
[15:23] <sil2100> psivaa: so that's something I did not know
[15:24] <sil2100> psivaa: ok, I'll prepare a merge for that then ;)
[15:24] <psivaa> sil2100: elopio: this is for specific packages. not sure if url-dispatcher-tools is a dep that should be installed by default
[15:24] <psivaa> sil2100: i'm just running the tests after installing. i guess we would propose the MP after confirming that it works
[15:25] <sil2100> psivaa: right ;)
[15:25] <didrocks> cjohnston: not sure, in some hours, why?
[15:25] <didrocks> cjohnston: well, if you don't speak about 244
[15:26] <sil2100> psivaa: I would say it's something we should really install when doing unity8 AP testing, but it's not required for normal system usage
[15:26] <balloons> sergiusens, got time this week to finish https://code.launchpad.net/~sergiusens/phablet-tools/emu_prov/+merge/207440?
[15:26] <didrocks> kgunn: yeah, it's still blockers, so as we can't revert, we'll need a fix
[15:26] <didrocks> kgunn: and please, add those manual tests then as nothing automated are catching them to your test plan
[15:27] <kgunn> didrocks: i launched apps, i guess i didn't measure them...
[15:27] <kgunn> didrocks: or maybe i was touching it too much
[15:27] <kgunn> if you touch...
[15:27] <didrocks> kgunn: yeah, not sure what system-settings/update-manager is doing to not have it
[15:27] <kgunn> the problem goes away
[15:27] <didrocks> kgunn: yeah
[15:28] <didrocks> kgunn: also, in system-settings, if there is a pending update, it will refresh
[15:28] <cjohnston> didrocks: to try to reproduce the issues we saw with the results not being published to the dashboard
[15:28] <kgunn> didrocks: we're on it...
[15:28] <didrocks> kgunn: excellent, thanks!
[15:28] <didrocks> cjohnston: so #244 should be under tests and proceed I guess?
[15:29] <cjohnston> doanac`: ^
[15:30] <psivaa> sil2100: unity8-autopilot should install url-dispatcher-tools but unity8-autopilot is no longer installed because unity8 is setup as click pkg
[15:31] <didrocks> kgunn: btw, just added a way to ensure system-settings doesn't refresh: https://bugs.launchpad.net/mir/+bug/1294053/comments/3
[15:31] <sil2100> Oh
[15:31] <sil2100> psivaa: that would explain why it *suddenly* started failing
[15:32] <doanac`> didrocks: it shows up here: http://ci.ubuntu.com/smokeng/
[15:32] <doanac`> but not here: http://ci.ubuntu.com/smokeng/trusty/touch/
[15:32] <doanac`> i'm debugging as we speak
[15:33] <sil2100> psivaa: so, is there a way to force dependencies for click packages?
[15:33] <seb128> Laney, what happened to you settings landing ask?
[15:33] <sil2100> psivaa: or maybe we can simply force in the unfra in the testconfig to install url-dispatcher during unity8 click testing?
[15:33] <sil2100> *infra
[15:33] <Laney> seb128: dbarth stole it
[15:34] <sil2100> psivaa: sicne I already see something is installed there -> pkgs=['python-gi']
[15:34] <Laney> line 12
[15:34] <seb128> oh
[15:34] <seb128> dbarth, you are missing a commit message
[15:34] <seb128> the CI failed to build due to it
[15:34] <psivaa> sil2100: looking.. just a sec
[15:34] <didrocks> doanac`: ok, thanks ;)
[15:36] <psivaa> sil2100: we could make the test pass by force installing that package.. but not sure if that's the right think and if we are masking a dep breakage in click setup
[15:37] <sil2100> psivaa: well, I don't know, as my knowledge of click-dependencies is close to 0 - I just know that from the deb side all is ok, and I don't even know if click apps can have 'dependencies'
[15:37] <sil2100> psivaa: and if click tests are packages in overall
[15:38] <sil2100> psivaa: since from what I remember, running click tests basically means: install click app, branch click apps bzr branch to get the tests and run
[15:38] <sil2100> psivaa: so, I don't remember basically anything like a 'click autopilot package', so anyway we have to resolve test dependencies manually for click - but I might be wrong
[15:40] <psivaa> sil2100: ok, i dont know either.. probably the person did the click migration of unity8 know better.. but it's fine by me for adding the pkg in testconfig.py
[15:40] <sil2100> psivaa: https://code.launchpad.net/~sil2100/ubuntu-test-cases/touch_url-dispatcher_unity8/+merge/211559 <- just in case ;)
[15:41] <sil2100> psivaa: just tell me if it's ok code-wise
[15:41] <sil2100> psivaa: and I'll poke someone from the unity8 team I suppose?
[15:42] <psivaa> sil2100: ack, will do. that would be better. thanks
[15:44] <seb128> dbarth, hello?
[15:47] <cjwatson> sil2100: not in click, although you're free to have x-* fields in the manifest specific to the test setup; in fact I thought there was something like that in place already
[15:49] <sergiusens> psivaa, do you know what happened to the servers at all?
[15:49] <sil2100> cjwatson: ok, thanks
[15:49] <sil2100> psivaa: anyway, for now I guess this should be the good way to go, as per the merge
[15:53] <dbarth> sergiusens: yup?
[15:53] <dbarth> sergiusens: sorry i meant seb128
[15:53] <dbarth> seb128: another issue? let me check that one
[15:54] <seb128> dbarth, you locked down ubuntu-system-settings in a silo which doesn't build due to missing commit message, please fix and get things moving, we have other changes to land
[15:54] <seb128> thanks ;-)
[15:54] <dbarth> seb128: doh
[15:54] <dbarth> seb128: or i can give you the MP back
[15:54] <dbarth> seb128: at least we know this one will merge, and you will be unblocked
[15:54] <dbarth> hang on
[15:55] <dbarth> seb128: https://code.launchpad.net/~cjwatson/ubuntu-system-settings/arch-any/+merge/211426 is yours
[15:55] <dbarth> seb128: i removed it
[15:55] <sil2100> psivaa: thanks! I'll fill in a bug for this maybe so that we don't loose track of this problem
[15:56] <psivaa> sergiusens: no, i couldn't find out. i probably need to ask plars if he knows of any possibility of udev rule changes
[15:56] <seb128> dbarth, thanks, but why did you merge it in your silo first?
[15:56] <psivaa> sil2100: thanks
[15:57] <plars> psivaa: on ashes?
[15:57] <Laney> buh
[15:57] <dbarth> seb128: to try to land it with the rest of the changes,but that doesn't seem to go fast enough
[15:57] <Laney> seb128: are your ones ready now?
[15:57] <plars> psivaa: what's the context of this?
[15:57] <dbarth> seb128: still, should i merge https://code.launchpad.net/~dbarth/ubuntu-system-settings-online-accounts/fix-ap-test2/+merge/211547 as well
[15:57] <plars> psivaa: there haven't been any recent changes that I'm aware of
[15:57] <dbarth> seb128: or would you rather have it to be unblocked as well?
[15:59] <sergiusens> plars, there was a general error that psivaa pointed me to which was confused with the channel change or image change I was told; but it seems all devices got disconnected at a certain time (access lost)
[15:59] <plars> sergiusens: fwiw, doanac` said he installed 243 at home and bricked his mako also.
[16:00] <sil2100> didrocks: you think it would be feasible for me to jump out around 18 today? It's nothing top-prio, just it would be most convinient for me to do it today before they close-up
[16:00] <plars> sergiusens: said he had to boot to the bootloader and rescue
[16:01] <didrocks> sil2100: would have been nice to have the team meeting for everyone at least. So maybe report now what's your progress?
[16:02] <sil2100> didrocks: so, we found the REAL problem with the unity8 url-dispatcher horror - and the root cause seems to be in the way the unity8 tests are being executed on smoketesting right now
[16:02] <sergiusens> plars, ok, would add up if psivaa saw it on 243, but it was 241 and all the tested devices
[16:02] <didrocks> sil2100: btw, I'm not there on Friday, I'll let you lead the meetings
[16:02] <sil2100> didrocks: ACK
[16:02] <didrocks> sil2100: ah, so server-side fix?
[16:02] <plars> sergiusens: no, it was after 241
[16:02] <plars> sergiusens: 241 worked fine, but when 242 flashed it had problems
[16:02] <seb128> dbarth, please merge it
[16:02] <dbarth> seb128: ok
[16:03] <sil2100> didrocks: yes, as it seems we're running unity8 tests like click-app tests, so we actually don't even install unity8-autopilot - so url-dispatcher-tools is missing as a dep from the system during executing the tests
[16:03] <sergiusens> plars, hmm psivaa pointed me to 241 iirc
[16:03] <psivaa> sergiusens: plars: the devices failed during installation of 242 actually
[16:03] <seb128> Laney, I've some ready yes
[16:03] <plars> sergiusens: I also tried for a while at home to reproduce it and couldn't, so I'm not sure what the magic combination is
[16:03] <sergiusens> ah right
[16:03] <seb128> Laney, I'm going to put a landing with what is ready
[16:03] <sil2100> didrocks: so, actually, url-dispatcher cannot be executed!
[16:03] <Laney> seb128: ok
[16:03] <plars> sergiusens: after we made all the changes yesterday, I watched 241 work just fine, and never had to touch it
[16:03] <didrocks> sil2100: ok, what's the fix needed/who is doing it/do you have the bug report for it? :)
[16:03] <sergiusens> doanac`, when you "bricked" your device; was it while clearing cache?
[16:03] <plars> sergiusens: so I was hoping that meant everything was fine
[16:04] <sil2100> didrocks: the fix is getting merged right now ;) Bug report: https://bugs.launchpad.net/unity8/+bug/1294121
[16:04] <sil2100> didrocks: I'll modify its contents
[16:04] <doanac`> sergiusens: not sure. i ran a job and the background and came back later to see it stuck
[16:04] <sergiusens> plars, yeah, I wasn't expecting any issues outside of channel selection
[16:04] <didrocks> sil2100: excellent, nice!
[16:04] <didrocks> sil2100: anything else to mention?
[16:04] <doanac`> sergiusens: FYI - 243 worked for me this time
[16:04] <sil2100> didrocks: elopio's eagle eye was most helpful ;)
[16:04] <didrocks> heh, great!
[16:05] <sil2100> didrocks: we have a safe buffer of free silos, like 4 right now, but I will publish one package pretty soon
[16:05] <didrocks> sil2100: ah, and any news on system-settings dbus tests?
[16:05] <sil2100> robru: just so you know, keep a look at the free-silo count and don't assign when we have less than 3-4 free silos
[16:06] <sergiusens> doanac`, ok, I haven't seen the issue either; but seemed strange in the jenkins log
[16:06] <sil2100> didrocks: so, we basically know how to proceed to have a fix for that, but I don't know if in the end anyone had the time to fix it! So I guess I'll have to do it
[16:06] <plars> sergiusens: do you know if anything changed on the android or bootloader side between 241 and 242?
[16:06] <didrocks> sil2100: argh, ok
[16:07] <robru> sil2100, right, sorry
[16:08] <sil2100> robru: no worries, it's just a safety net for emergency landings
[16:08] <sil2100> kgunn: any progress on the regressions :) ?
[16:08] <sergiusens> plars, nothing should have; I don't see anything after a quick look either
[16:09] <kgunn> sil2100: only thing we know is that buffers aren't posting to the display buffer unless there's a touch event
[16:09] <robru> didrocks, re the changelog issue, also jdstrand had the exact same thing. previous release was tagged, citrain couldn't find it and made a big ugly wrong changelog
[16:09] <kgunn> we're in the midst of debuggging now
[16:09] <didrocks> robru: look at the bug :)
[16:10] <didrocks> psivaa: do you know where the sdk tests are?
[16:10] <didrocks> psivaa: I think it needs to be updated, Checking if 'libqt5v8-5-dev' is available... !NOT FOUND!
[16:10] <didrocks> this package won't exist anymore
[16:11] <sil2100> robru: I published landing 12
[16:12] <robru> sil2100, thanks
[16:12] <psivaa> didrocks: looking, 1 sec. please
[16:13] <sil2100> robru: most of the landings that are not assigned were actually (and probably still are) blocked by other silos
[16:14] <robru> sil2100, how much can still be blocked? now that qt52 is in shouldn't everything be unblocked?
[16:15] <sergiusens> robru, hey; can I get a silo for l40/goget-ubuntu-touch ?
[16:16] <sil2100> robru: well, many landings are related to the same components, so they block eachother
[16:17] <robru> sil2100, ^^ what do you think, do we have enough free silos for this? ;-)
[16:17] <sil2100> robru: like line 28 is blocked by 16
[16:18] <psivaa> didrocks: sdk tests run the tests from http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-qtcreator-plugins/trunk/view/head:/tests/device/check-packages
[16:18] <sil2100> robru: we have 5 silos free, so I guess we do ;)
[16:19] <robru> sergiusens, ok, one sec
[16:21] <robru> sergiusens, ok you got silo 14
[16:21] <sergiusens> thanks
[16:21] <robru> you're welcome
[16:28] <didrocks> bzoltan1: I think you want to update that test ^
[16:28] <didrocks> robru: we need to double check everything
[16:28] <didrocks> robru: until we can promote an image
[16:31] <dbarth> sil2100: help, i trashed my ppa, can your remove packages there: https://launchpad.net/~ci-train-ppa-service/+archive/landing-020/+packages
[16:32] <dbarth> it says i'm stuck because of old packages: http://162.213.34.102/job/landing-020-1-build/3/console
[16:32] <dbarth> (last lines)
[16:32] <sil2100> dbarth: hmmm
[16:32] <sil2100> dbarth: looking
[16:33] <sil2100> dbarth: ah, you reconfigured the silo to remove ubuntu-system-settings?
[16:33] <robru> didrocks, what's wrong now? I tested quite a lot yesterday
[16:34] <cjohnston> didrocks: fwiw.. the 'live' results are showing up http://ci.ubuntu.com/smokeng/ubuntu/  .. it looks like the system-images.u.c changes broke this too
[16:34] <didrocks> robru: well, there is already the whole list of unfixed issues from yesterday's email
[16:35] <didrocks> cjohnston: yeah, doanac` told that and work on a fix apparently :)
[16:35] <didrocks> robru: and Mir created 3 new bug reports
[16:35] <cjohnston> sorry.. missed him telling you :-)
[16:35] <didrocks> cjohnston: no worry, but thanks for hinting it! ;)
[16:36] <robru> didrocks, but if we are getting test results then the mir landing was an improvement ;-)
[16:36] <robru> no wait
[16:36] <robru> crap
[16:36] <robru> ;-)
[16:36] <robru> unity8
[16:36] <sil2100> dbarth: anyway, removing it from the PPA, it will take a while once it's noticable
[16:36] <dbarth> sil2100: yes i removedit, that's why
[16:37] <dbarth> sil2100: thanks
[16:37] <psivaa> sil2100: elopio: http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-daily/26/testReport/unity8.application_lifecycle.tests.test_url_dispatcher/URLDispatcherTestCase/test_alternate_swipe_out_application_started_by_url_dispatcher_Native_Device_/
[16:37] <didrocks> robru: yeah, that was unity8
[16:37] <psivaa> sil2100: elopio: this is after the merge from sil2100 for url-dispatcher-tools
[16:37] <sil2100> psivaa: what about the other test?
[16:37] <didrocks> robru: couldn't get the same flaky test than you on unity8, so yeah, ENOISSUE for now :p
[16:37] <sil2100> psivaa: is it still failing?
[16:37] <sil2100> dbarth: be sure to rebuild the silo, since I see signon-ui missing and such
[16:38] <robru> didrocks, so what's the plan then? reverting mir?
[16:38] <dbarth> sil2100: ah ok
[16:38] <didrocks> robru: not easy though
[16:38] <didrocks> robru: due to the ABI breakage and new binary packages…
[16:38] <psivaa> sil2100: this is the only failure that i see, on the first run after the merge
[16:38] <didrocks> robru: so, we're stuck on the Mir team to find a fix
[16:38] <robru> ugh, sorry
[16:38] <sil2100> psivaa, elopio: I see that the main test doesn't fail
[16:38] <didrocks> robru: no worry, I think we just need to add the 3 new bugs results on the testing procedure
[16:38] <sil2100> psivaa, elopio: so it seems only the 'alternate' version has problem, so not bad \o/
[16:39] <sil2100> The alternate version was simply there for more debugging
[16:40] <robru> didrocks, good call
[16:46] <elopio> psivaa, sil2100: interesting.
[16:46] <elopio> but, yes, now the original one passes, which was the important thing.
[17:14] <seb128> sil2100, can you approve l41, it's a setting landing that includes the mp to unblock build on other arches for other components (the one which was already discussed earlier)
[17:22] <boiko> cjwatson: we will disable the tests on powerpc for now, renato found that the test server is not starting up, but could not figure out why
[17:22] <bzoltan1> didrocks:  true... the libqt5v8-5-dev is gone
[17:22] <boiko> cjwatson: we can revisit that once we flush the queue of MRs that are piling up
[17:23] <cjwatson> boiko: ok
[17:24] <didrocks> bzoltan1: you will update the tests? Should be one line removal
[17:27] <bzoltan1> didrocks:  häh??? where did you get that project????
[17:27] <didrocks> bzoltan1: psivaa mentionned those tests were in ubuntu-qtcreator-plugins
[17:27] <didrocks> bzoltan1: http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-qtcreator-plugins/trunk/view/head:/tests/device/check-packages
[17:27] <didrocks> so I guess it's you? :)
[17:28] <bzoltan1> didrocks: :) this project is not used
[17:28] <bzoltan1> didrocks: http://bazaar.launchpad.net/~ubuntu-sdk-team/qtcreator-plugin-ubuntu/trunk/files
[17:28] <didrocks> bzoltan1: what do you mean? It's the sdk test that are executed apparently on the smoketest
[17:28] <Saviq> doanac`, hey, looks like we need to close the keyboard shortcuts hint somewhen https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/3521/artifact/results/autopilot/artifacts/unity8.shell.tests.test_emulators.DashAppsEmulatorTestCase.test_get_applications_should_return_list_with_names%20%28Desktop%20Nexus%2010%29.ogv :)
[17:29] <didrocks> bzoltan1: maybe the CI system needs to be updated, can you coordinate with them?
[17:29] <bzoltan1> didrocks: http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-qtcreator-plugins/trunk/revision/292
[17:29] <didrocks> to use qtcreator-plugin-ubuntu
[17:30] <doanac`> Saviq: is that happening consistently?
[17:30] <didrocks> plars: FYI ^
[17:30] <Saviq> doanac`, yes, it's always there
[17:30] <Saviq> doanac`, 'cause unity7 added this on first startup
[17:30] <bzoltan1> didrocks:  I have no idea where and who digged up this fossil :)
[17:30] <didrocks> bzoltan1: I think it was never updated
[17:30] <Saviq> doanac`, I can't say it actually interferes with our tests, but would like not to see it there before saying it is not
[17:30] <Saviq> :)
[17:30] <didrocks> bzoltan1: so, the new project is updated?
[17:30] <didrocks> for those tests?
[17:31] <doanac`> Saviq: ack. thanks
[17:31] <Saviq> doanac`, want me to file a bug?
[17:32] <didrocks> bzoltan1: I'll let you coordinate with doanac` or plars on this :)
[17:32] <bzoltan1> didrocks: there are no tests for the QtC as AP can not drive it yet
[17:32] <doanac`> Saviq: that would be helpful. thanks
[17:32] <plars> that's not something the smoke runs would need to care about right? looks like a desktop test
[17:33] <didrocks> bzoltan1: did the old tests have any value to resurect?
[17:33] <didrocks> bzoltan1: or should we just kill all sdk tests?
[17:33] <bzoltan1> didrocks:  I am happy to coordinate, but there is not much to coordinate here :) just drop that project as it is obsolate for 8 months
[17:33] <doanac`> drop the test for "sdk"?
[17:33] <Saviq> doanac`, bug #1294233
[17:33] <doanac`> or one of the tests in the sdk?
[17:33] <didrocks> doanac`: that's what I'm trying to get at :)
[17:33] <bzoltan1> didrocks: there is no automatic tests for QtC and its plugins
[17:34] <didrocks> bzoltan1: ok so we remove http://ci.ubuntu.com/smokeng/trusty/touch/mako/243:20140318:20140304/7236/sdk/
[17:34] <didrocks> right?
[17:34] <bzoltan1> didrocks: let me check what is that
[17:34] <doanac`> bzoltan1: here's the command we use to find what tests to run:
[17:34] <doanac`> http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/tests/sdk/tslist.auto
[17:34] <doanac`> "discovery_cmd"
[17:35] <bzoltan1> doanac`: didrocks: Now I see
[17:36] <mhr3> robru, can i get silo for #43?
[17:36] <bzoltan1> doanac`: didrocks: that was a test for checking if the Qt/QML APIs and the basic device connectivity packages are available on the image ... actually not a stupid tests, but we have not migrated that set to the new project... no idea why not.
[17:36] <robru> mhr3, sure
[17:37] <bzoltan1> doanac`: didrocks: please give me some time to check it... sure i can move that
[17:37] <doanac`> bzoltan1: let me know if you need anything from my end.
[17:37] <robru> mhr3, ok you got silo 12
[17:37] <didrocks> bzoltan1: good :)
[17:38] <didrocks> bzoltan1: while you move, remove the qt5 v8 packages :)
[17:38] <bzoltan1> doanac`: the thing here is that that obsolate project will not even build with qt 5.2
[17:38] <seb128> shrug
[17:38] <bzoltan1> didrocks:  certainly will do so
[17:38] <seb128> could somebody give us a silo for l41? that's blocking packages in proposed
[17:39] <bzoltan1> didrocks: doanac`: but for the meantime I pushed the fix to that fossil project... let the machine chew on it
[17:40] <didrocks> bzoltan1: great!
[17:40] <didrocks> bzoltan1: sounds like a good plan :)
[17:42] <Laney> seb128: We could just upload it for now
[17:43] <Laney> It's easy to tick the override button on the train
[17:47] <seb128> didrocks, sil2100: ^ ok if we manually upload u-s-s? we are failing to get a slot for that since this morning and things are blocked in proposed waiting on it
[17:47] <didrocks> seb128: did you ping the US team?
[17:47] <didrocks> sil2100 isn't around
[17:48] <didrocks> I see no reason/slot missing as we speak
[17:48] <seb128> no, sil2100 was looking at it earlier to I tried to ping him again
[17:48] <didrocks> argh :/
[17:48] <didrocks> ok, let me do it…
[17:48] <didrocks> seb128: line?
[17:48] <seb128> didrocks, I'm fine pinging cyphermox or robru
[17:48] <seb128> r41
[17:48] <seb128> l41
[17:48] <robru> seb128, hey need a silo?
[17:48] <cyphermox> oi
[17:49] <didrocks> (on it)
[17:49] <robru> didrocks, beat you ;-)
[17:50] <robru> seb128, silo 17
[17:50] <didrocks> robru: seems so :)
[17:50] <didrocks> thanks ;)
[17:50] <seb128> didrocks, robru: thanks
[17:50] <robru> seb128, you're welcome
[17:51] <Laney> unfortunate series of frustrations on that one
[17:51] <Laney> we could have uploaded that >6 hours ago
[17:51] <Laney> oh well
[17:52] <seb128> Laney, I didn't follow, what was the issue why we didn't get the silo first
[17:52] <seb128> was there really u-s-s listed in another landing?
[17:52] <seb128> or was that a bug in the tool/did that got figured out?
[17:53] <seb128> Laney, and then how did it end up being merged in the online stuff silo?
[17:54] <Laney> That was the other landing
[17:54] <Laney> I think d_barth just grabbed it because he thought it would be good to get in
[17:54] <seb128> oh, ok
[17:54] <seb128> overzealous lander :p
[17:55] <Laney> yeah...
[17:56] <dbarth> robru: hi; i finished testing silo 006 (desktop and phone to check for potential regressions)
[17:56] <dbarth> robru: so this one is good for publish
[17:56] <robru> dbarth, excellent, thank you!
[18:02] <doanac`> Saviq: as per the shortcut hints showing up. Is there a gsettings value to disable this?
[18:07] <balloons> davmor2, you have a flo?
[18:10] <Saviq> doanac`, there must be something, but I'm not sure what
[18:10] <boiko> robru: hi, do you by chance know what went wrong in this build: https://launchpadlibrarian.net/169942666/buildlog_ubuntu-trusty-ppc64el.address-book-app_0.2%2B14.04.20140318.2-0ubuntu1_FAILEDTOBUILD.txt.gz
[18:11] <robru> boiko, checking
[18:11] <boiko> robru: just trying to understand if this is something transient in the builder, or if it is something I need to look into
[18:12] <robru> boiko, wow, never saw that one before
[18:12] <boiko> robru: should I just try rebuilding it?
[18:12] <robru> boiko, yeah, for now
[18:13] <cjwatson> I've seen that in a couple of cases where the builder was about to go insane
[18:13] <cjwatson> infinity: ^-
[18:13] <cjwatson> dpkg-deb: building package `address-book-app-dbg' in `../address-book-app-dbg_0.2+14.04.20140318.2-0ubuntu1_ppc64el.deb'.
[18:13] <cjwatson> Can't use an undefined value as a subroutine reference at /usr/bin/dh_builddeb.pkgbinarymangler line 118.
[18:13] <cjwatson> END failed--call queue aborted at /usr/bin/dh_builddeb.pkgbinarymangler line 118.
[18:13] <robru> boiko, there you have it, infrastructure issue
[18:13] <infinity> cjwatson: That's a sign that things are going to go south, yeah.
[18:13] <cjwatson> postal01 again
[18:14] <boiko> robru: ok, thanks, I will rebuild. this address-book stuff is cursed it seems :)
[18:14] <robru> boiko, yeah ;-)
[18:14] <infinity> I think I need to wipe and reimage all of those so I have a hope of debugging this sanely if it happens again.
[18:14] <bfiller> cjwatson: do you think a rebuild will sort it or does some other action need to be taken?
[18:14] <cjwatson> bfiller: rebuild will sort it if it doesn't hit the same machine
[18:14] <infinity> It won't. :P
[18:14] <boiko> bfiller: cjwatson: I triggered a rebuild, let's see what happens
[18:14] <cjwatson> (e.g. if we put postal01 on manual; which I'm not going to do now since it's dinnertime)
[18:14] <cjwatson> ah, which infinity has done :)
[18:15] <infinity> Retried.
[18:15] <infinity> boiko: "Triggered a rebuild"?
[18:15]  * infinity retired the actual failed build...
[18:15] <infinity> boiko: You didn't trigger a whole fresh upload, did you? :/
[18:15] <cjwatson> if so, please don't do that again, it wastes time on all architectures and just generally introduces confusion for no reason
[18:16] <boiko> infinity: nope, just asked in the citrain spreadsheet to build only the address-book-app
[18:16] <cjwatson> well that may well trigger a fresh upload
[18:16] <infinity> boiko: Yes, that's what I meant.  Don't do that.
[18:16] <boiko> infinity: sorry, what should I do instead?
[18:16] <infinity> boiko: The build itself can be retried, doing a new upload is a horrible waste of resources.
[18:16] <boiko> infinity: I mean, in order to rebuild it and clean the status on the spreadsheet
[18:16] <cjwatson> either a member of launchpad-buildd-admins or a member of ci-train-ppa-service can retry individual builds.
[18:16] <infinity> (Which I did...)
[18:17] <boiko> infinity: cjwatson: ah ok, sorry about that, I will request a rebuild of the individual arch/component next time
[18:17] <ogra_> grrr bootchart ... stop playing tricks on me !
[18:18] <bfiller> cjwatson: is it intended that the CI Train will block on failed powerpc, arm64 and ppc64el builds? seems like this is something new
[18:18] <ogra_> why does --crop-after=unity8 sometimes work and sometimes it doesnt
[18:18] <infinity> bfiller: It's intended if they succeeded previously.
[18:18] <infinity> bfiller: We don't tolerate regressions.  If it's always failed, it can continue to fail.
[18:18] <boiko> cjwatson: infinity: so, should I cancel the build I requested or just leave it running?
[18:18] <bfiller> infinity: previously as in when?
[18:19] <cjwatson> bfiller: https://wiki.ubuntu.com/ProposedMigration
[18:19] <sergiusens> robru, can you publish this? https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=23 given it's sensitivity, you might want to go through it again, but mandel and barry already gave their +1s
[18:19] <cjwatson> boiko: cancel if you still can
[18:19] <cjwatson> boiko: if not, not the end of the world
[18:19] <boiko> cjwatson: just did.
[18:19] <infinity> bfiller: Which specific case are you looking at, so we're not talking hypotheticals.
[18:19] <cjwatson> bfiller: that is, if 'rmadison -s trusty' reports that the package is in a given arch, then new uploads need to build on that arch too
[18:19] <robru> sergiusens, checking
[18:20] <cjwatson> bfiller: there are ways to override this if it gets stuck, but "don't regress" is a sane default I'll stand behind.
[18:20] <bfiller> cjwatson: ok
[18:20] <infinity> Given that regressions usually point to real bugs in the code, yes.
[18:20] <infinity> It's about 1% toolchain bugs and 99% programming errors. :P
[18:20] <infinity> (Well, throw in packaging bugs there too, but that's part of the 99%)
[18:20] <cjwatson> boiko: I think you were too late.
[18:20] <bfiller> infinity: well address-book-service, address-book-app and gallery-app have had problems in the last few days on these architectures. wasn't aware if they were previously succedding or not
[18:21] <robru> sergiusens, published
[18:21] <cjwatson> bfiller: gallery-app I sat up to 2am debugging, so I'd kind of appreciate not having the implication that it's an imposition on others ...
[18:21] <boiko> cjwatson: ouch, it won't cause problem, will it?
[18:21] <cjwatson> boiko: waste of resources, but it'll get there.
[18:21] <infinity> boiko: No, you just pushed out a new version for no reason, that's all.  It'll be fine.
[18:22] <bfiller> cjwatson: not implying anything, just asking if it had previously been passing on those archs
[18:22] <cjwatson> bfiller: the others have built before; we'll need to either fix them (which I understood to be in progress, at least by disabling tests for the time being which isn't ideal but hey) or remove the old binaries
[18:22] <bfiller> cjohnston: I appreciate you fixing it, believe me :)
[18:22] <cjwatson> you can look.
[18:22] <infinity> address-book-app looks fine in landing-011
[18:23] <cjwatson> $ rmadison -s trusty address-book-{app,service} gallery-app
[18:23] <cjwatson>  address-book-app     | 0.2+14.04.20140307-0ubuntu1     | trusty/universe | source, amd64, armhf, i386, powerpc
[18:23] <cjwatson>  address-book-service | 0.1.1+14.04.20140317.1-0ubuntu1 | trusty/universe | source, amd64, arm64, armhf, i386, ppc64el
[18:23] <cjwatson>  gallery-app          | 0.0.67+14.04.20140307-0ubuntu1  | trusty/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el
[18:23] <cjwatson> address-book-app has in fact progressed in trusty-proposed, and builds everywhere now.
[18:26] <infinity> cjwatson: That perl-goes-insane-and-takes-userspace-with-it thing has only ever been seen on postal*, right?
[18:26] <infinity> I wonder if maybe the host system could just use a reboot and magically would love me again.
[18:34] <kgunn> robru: good day!...any chance you could hook me up with a silo ? its just mir. line44 in the sheet
[18:34] <robru> kgunn, hmmmm we're really short on silos. but I guess mir is important
[18:35] <kgunn> robru: so i've heard ;)
[18:35] <robru> kgunn, ok, you got 18 ;-)
[18:35] <kgunn> woopwoop
[18:36]  * kgunn makes train whistle noise
[18:42] <boiko> cjwatson: so, now that the address-book-app is finished building on the PPA, will the spreadsheet status get updated automatically at some point? or do I need to do some manual step to get it to reflect the correct status?
[18:44] <davmor2> balloons: I do have a flo
[18:47] <balloons> davmor2, anything weird while using OTA updates? like a slow dl, no progress bar updates, disappearing ui inside updates?
[18:47] <ToyKeeper> I don't know about you, but my flo seems to get pretty slow wifi transfers...  even from the local network.
[18:47] <davmor2> balloons: there is a nice mir bug that is causing issues
[18:48] <sergiusens> robru, can you publish silo 014?
[18:48] <balloons> ToyKeeper, I agree
[18:48] <ogra_> worked fine for me today
[18:48] <balloons> davmor2, yes I see it quite a bit
[18:48] <balloons> ot sure 244 made it better or worse
[18:48]  * ogra_ tires an OTA ... noticing there is a new image
[18:48] <robru> sergiusens, yes!
[18:48] <sergiusens> thanks
[18:49] <davmor2> balloons: it's working I'd say 10-15% slower than mako I see the progress bar
[18:49] <ogra_> i get about 1% per second in the progressbar ... thats not worse than the other devices here
[18:50] <ToyKeeper> OTOH, it just got the r244 update downloaded in about as much time as it took me to get to the updates tool to tell it not to do it automatically.
[18:51] <davmor2> ogra_, balloons: I'm on a 72mbit/s connection it's pretty nippy here however it's is definitely not as fast as mako but not drastically slower either
[18:51] <ogra_> mine is in recovery now ... didnt feel particulary slow
[18:51] <ToyKeeper> Hmm, time zone weirdness.  It thinks Denver is UTC+1.
[18:51] <ogra_> oh, then you only have 70M more than me :P
[18:51] <davmor2> ogra_: getting a free upgrade to 100 soon :)
[18:52] <ogra_> pfft
[18:53] <ToyKeeper> Hmm, 16mbit/s here...  but the flo seems to max out at about 1.5mbit/s.
[18:53] <ToyKeeper> At least, it did last time I checked.
[18:55] <ToyKeeper> Nope, nevermind.  Whatever was causing that seems fixed now.  Getting closer to 8mbit/s on it now.
[18:58] <ToyKeeper> Oh, there's a fun bug.  The music scope shows every song in an album as if it's the same.
[18:59] <ogra_> you mean it shows the same cover art ?
[18:59] <balloons> for comparision, mako updates in <1 min.. flo is several mins
[18:59]  * ogra_ bets popey has a bug open for that 
[19:01] <popey> i dont
[19:01] <ToyKeeper> http://toykeeper.net/tmp/music-scope-no-title.jpg
[19:02]  * ogra_ loses his faith 
[19:02] <popey> hah
[19:02] <ogra_> :)
[19:02] <ToyKeeper> vs http://toykeeper.net/tmp/home-scope-has-title.jpg
[19:02] <boiko> robru: hey, after the packages were manually rebuilt in the ppa, do I need to do something to get the spreadsheet status correctly updated?
[19:03] <robru> boiko, which silo
[19:03] <robru> boiko, and what do you mean "manually rebuilt"
[19:03] <cjwatson> infinity: postal> yes, as far as I know
[19:03] <boiko> robru: landing-011
[19:03] <sergiusens> rsalveti, care to give a final view and push to https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=25 ?
[19:04] <boiko> robru: infinity triggered a rebuild of address-book-app in ppc64el (because of that weird failure)
[19:04] <cjwatson> boiko: it should notice, since that build was triggered in jenkins
[19:04] <cjwatson> boiko: infinity's retry has become essentially irrelevant since you triggered a fresh upload to the PPA
[19:04] <infinity> boiko: My retry is meaningless now, since you overwrote it with a newer version.
[19:04] <davmor2> ToyKeeper: it's to do with a short coming in the carousel for the dash aiui it might get fixed with the new scopes
[19:04] <robru> boiko, oh I see. in this case you should run the build job, but set the flag WATCH_ONLY. then it will find the build complete and update the status
[19:04] <popey> ToyKeeper: same goes for video carosel
[19:04] <boiko> cjwatson: but I hit cancel :)
[19:04] <cjwatson> oh right
[19:04]  * davmor2 tries thinking back to the mwc image
[19:04] <popey> ToyKeeper: want me to file a bug?
[19:05] <cjwatson> yeah, what robru said then
[19:05] <boiko> robru: nice! let me try that
[19:05] <ToyKeeper> popey: Sure, if you like.  I mostly wanted to check if it was known.
[19:05] <popey> ToyKeeper: will do now
[19:05] <ToyKeeper> (and I'm not totally sure which project the bug goes in)
[19:06] <rsalveti> sergiusens: done
[19:08] <cjwatson> boiko: looks like it's found it now
[19:08] <boiko> cjwatson: yep, good, thanks
[19:08] <boiko> robru: so, now that the status is OK in the spreadsheet, I switched landing-011 to testing done (I was testing while waiting for the status to change)
[19:08] <robru> boiko, excellent, thank you
[19:09] <boiko> robru: could you please publish that?
[19:09] <sergiusens> rsalveti, thanks
[19:09] <robru> boiko, as you wish!
[19:09] <boiko> :)
[19:09] <sergiusens> robru, can I get a silo for l30/qtubuntu?
[19:10]  * sergiusens is on a publishing roll today when compared to yesterday
[19:10] <robru> sergiusens, hrmmmm, does it contain urgent bugfixes? there are only 2 silos left, need to marshall these at the moment
[19:10] <sergiusens> robru, as soon as the ones I have are freed (3 migrating) is fine
[19:10] <sergiusens> unless more are urgent
[19:10] <sergiusens> it's to unblock oxide
[19:11] <robru> sergiusens, yeah, let's wait an hour or so to free your other silos.
[19:11]  * ogra_ notes that secretly preparing some silo PPAs and selling them here could become a good busines
[19:11] <ogra_> s
[19:11] <cjwatson> sorry for squatting on one for click, I had to sidetrack into unbreaking my phone from the dual-boot 0/0/0/0/0 thing
[19:11] <sergiusens> ogra_, or just dput? :-P
[19:11] <ogra_> muhahah
[19:11] <robru> cjwatson, no worries.
[19:11] <cjwatson> might manage to test that later this evening, or at any rate first thing tomorrow
[19:12] <popey> ToyKeeper: bug 1294294
[19:12] <ToyKeeper> popey: Thanks.
[19:12] <sergiusens> bfiller, do you know if any of the gallery landings you have have xnox's python3 test fixes?
[19:14] <bfiller> sergiusens: no they don't
[19:14] <bfiller> sergiusens: the current landing is blocked with a libthumbnailer crash
[19:14] <bfiller> sergiusens: maybe we can get them into the next one
[19:14] <bfiller> sergiusens: have about 100 branches for gallery to get merged
[19:15] <cjwatson> 100!  No wonder you're in a rush :)
[19:15] <sergiusens> I imagine
[19:15] <bfiller> I exaggerate :) but we do have many
[19:17] <cjwatson> bfiller: well, now you know how the release team feels trying to orchestrate all the build failures, proposed migrations, etc. :-)
[19:17] <bfiller> cjwatson: I feel your pain
[19:18] <balloons> ToyKeeper, davmor2 does file manager work on your flo?
[19:19] <davmor2> balloons: you on the latest image?
[19:19] <balloons> davmor2, 244
[19:20] <davmor2> balloons: there is a mir issue that mean apps appear grey if you tap them or rotate the device it refreshes the screen and then it is all drawn
[19:20] <ToyKeeper> balloons: It runs, it lets me browse directories, it took like 30 seconds to update when I told it to show me a dir with a single album in it.  (and then left the "updating" icon frozen onscreen until the screen timed out)
[19:20] <davmor2> balloons: a fix is wending it's way to silo near the ci train :)
[19:21] <balloons> ToyKeeper, kk, ty.
[19:21] <davmor2> balloons: yes so tap the screen on the grey page
[19:21] <ToyKeeper> Hey, it actually launched music this time.  Last time I tried that, it didn't know how to open a music file.
[19:22] <ToyKeeper> davmor2: I definitely see that mir bug now.
[19:23] <ToyKeeper> (but it's not just showing a grey screen...  apps are visually locking at pretty much any time)
[19:23] <davmor2> ToyKeeper: yeap
[19:23] <davmor2> it's not pretty
[19:23] <ToyKeeper> Is there a bug already?
[19:24] <davmor2> ToyKeeper: yeap there were 3, all three are fixed but need  to land
[19:24] <balloons> davmor2, there's not grey page.. it simply doesn't launch, hence my asking
[19:24] <davmor2> balloons: ^
[19:29] <ToyKeeper> Oh, hey, new mirscreencast bits landed.
[19:35] <boiko> robru: just curious, this page: https://launchpad.net/ubuntu/+source/address-book-service already shows the latest version of addres-book-service available in proposed, but rmadison doesn't, shouldn't they be showing the same thing?
[19:36] <robru> boiko, in theory, yes. in practise there is a few minutes delay from one to the other
[19:36] <robru> boiko, in case of discrepancy, rmadison is considered correct.
[19:37] <boiko> robru: ah ok, so I will give it some time, thanks
[19:37] <davmor2> ToyKeeper, balloons: by the way if the guys land a new mir in an image and you guys are about please test that apps open faster, the setting app is nolonger grey, and when you rotate terminal or settings it actually rotates all the way :)  Thanks guys :)
[19:37] <robru> boiko, yep, you're welcome
[20:06] <sergiusens> robru, now that two silos have been released; can I get my qtubuntu silo?
[20:13] <robru> sergiusens, oh yeah, right.
[20:14] <robru> sergiusens, which line was that?
[20:14]  * sergiusens looks
[20:14] <robru> 30?
[20:15] <sergiusens> robru, yeah, 30
[20:15] <robru> sergiusens, ok, you got silo 11
[20:17] <sergiusens> thanks
[20:18] <robru> you're welcome
[20:20] <cyphermox> seb128: silo 5 btw
[20:24]  * balloons awaits mir fix :)
[20:25] <ToyKeeper> At least it's unanimous that r244 is a big red fail.
[20:28] <seb128> cyphermox, thanks
[20:31] <Saviq> doanac`, it's ~/.cache/unity/first_run.stamp
[20:33] <seb128> Laney, cjwatson: ok, u-s-s built but now is blocked in proposed due to indicator-network missing on arm64/ppc64el :/
[20:37] <balloons> ToyKeeper, re: flo updating i noticed it pulled 352mb; a full image and not a diff
[20:38] <balloons> I wonder if diff updates aren't working on flo or did that much really change to require it?
[20:52] <ToyKeeper> balloons: No clue.  I barely got a chance to see it happening before it finished, because I forgot to disable automatic updates before turning on wifi.
[20:54] <Saviq> cihelp: q: could otto and mediumtests differentiate between FAILED and UNSTABLE when reporting results?
[20:55] <Saviq> actually, otto seems fine, but mediumtests-touch don't
[21:02] <cjwatson> seb128: that'd be https://code.launchpad.net/~cjwatson/indicator-network/porting/+merge/210394
[21:03] <seb128> cjwatson, do you know if anyone is landing that one?
[21:03]  * seb128 checks the googledoc
[21:03] <cjwatson> seb128: I thought I saw it somewhere ...
[21:04] <seb128> shrug
[21:04] <seb128> thostr has a landing for it on l26
[21:05] <seb128> but it's listed with an upstart-app-launch change that is blocked on another silo
[21:06] <seb128> cyphermox, robru: is the status of l26 still current? I don't see upstart-app-launch in any silo?
[21:06] <cjwatson> seb128: that's an upstart-app-launch MP I withdrew as no longer needed
[21:06] <seb128> oh, sorry, it is in l24
[21:06] <seb128> cjwatson, ok, good
[21:06] <cjwatson> seb128: should probably ditch the upstart-app-launch bit and land indicator-network separately
[21:07] <seb128> cyphermox, robru: can we get l25 reconfigured to not include the upstart-app-launch change?
[21:07] <cyphermox> yeah
[21:07] <cyphermox> hold on
[21:07] <seb128> thanks
[21:07] <cyphermox> so line 24, 25, or 26? :)
[21:07] <cjwatson> it's 25
[21:07] <seb128> just 25
[21:07] <seb128> drop the upstart-app-launch mp, keep the indicator one only
[21:07] <seb128> then give it a silo
[21:07] <seb128> that's blocking other things in proposed
[21:08] <seb128> thanks ;-)
[21:08] <cyphermox> np
[21:08] <cjwatson> we'll get down the stack eventually :)
[21:08] <seb128> cjwatson, cyphermox: thanks
[21:08] <cjwatson> one-time pain I think
[21:08] <cjwatson> hm, indicator-network Depends: unity8
[21:09] <seb128> does that mean more fun to come?
[21:09] <cjwatson> we may have to force this
[21:09] <cyphermox> it's being blocked by landing-002 too
[21:09] <cjwatson> IMO we ought to get unity8 working everywhere, but it'll take a bit longer
[21:10] <cyphermox> mhr3: can we please get the connectivity stuff landed? otherwise I'd be tempted to skip over it, build this thing, but you'll need to remember to rebuild all your packages after the fact
[21:11] <cjwatson> what I could do is pretend that indicator-network exists
[21:11] <seb128> cyphermox, can you get that one out of the way? it's not even building
[21:11] <cjwatson> or, if we land indicator-network, pretend that unity8 exists
[21:11] <cyphermox> wait
[21:11] <seb128> cyphermox, I'm sure mhr3 can land that tomorrow, he's probably eod
[21:11] <cyphermox> why is indicator-network depending on unity8?
[21:11] <seb128> the indicator one should be trivial by itself
[21:11] <cjwatson> then at least it'll be a confined thing rather than just leaving an uninstallable around
[21:11] <cyphermox> there should be a desktop side of it that should just work on desktop
[21:12] <cyphermox> indicator-network uninstallable is a regression
[21:12] <cjwatson>     * Interfaces with unity8's extended snap decisions.
[21:12] <cjwatson> maybe that?
[21:12] <cyphermox> ridiculous
[21:12] <mhr3> seb128, cyphermox, i haven't heard anything new from Wellark about it, so feel free to skip
[21:12] <cyphermox> mhr3: thanks, I will
[21:12] <cjwatson> Yeah, that's what introduced the dep
[21:12] <cjwatson> http://launchpadlibrarian.net/152497538/indicator-network_0.5.0%2B13.10.20130918-0ubuntu1_0.5.1%2B13.10.20131004-0ubuntu1.diff.gz
[21:13] <cjwatson> Maybe that was really a badly spelled Breaks: unity8 (<< 7.82)?
[21:13] <cjwatson> I don't know whether the indicator fails to start without unity8
[21:13] <seb128> cyphermox, that indicator should probably have its desktop profile disabled, it's pretty useless on desktop atm and it leads to quite some unity8 testers complaining about having a duplicated indicator in unity7 sessions
[21:15] <cyphermox> they can remove the packages
[21:15] <seb128> that uninstalls e.g unity-system-settings
[21:15] <cyphermox> if we want to ever manage to get testing for indicator-network and eventually migrate to it it will have to be installable one day
[21:15] <seb128> I keep editing the .settings to drop the .desktop here
[21:15] <seb128> (should probably dpkg-divert it)
[21:16] <cyphermox> this is madness
[21:16] <seb128> why?
[21:16] <seb128> the settings use it as a backend
[21:16] <seb128> but that doesn't mean I want that indicator in my desktop session
[21:16] <cyphermox> backend is different from the indicator render bits
[21:16] <seb128> right, but we don't have a way to flag that atm
[21:16] <seb128> we either export a desktop profile or not
[21:17] <cyphermox> it should be in a separate package
[21:17] <cyphermox> currently there is a desktop profile
[21:17] <seb128> right
[21:17] <seb128> you can't have separate package, that the same binary
[21:17] <cyphermox> that ought to be fixed eventually
[21:17] <seb128> ubuntu-system-settings use the phone profile
[21:17] <cyphermox> I'm not disagreeing that we should blow it away if it's really a blocker for touch
[21:18] <seb128> blocker for touch?
[21:18] <cyphermox> but I'm pissed that there are so many dependency messes and broken things, and uninstallable, unfixable things
[21:18] <seb128> not sure we are talking about the same thing
[21:18] <seb128> oh
[21:18] <seb128> the "depends on unity8" is orthogonal to the "shouldn't be in desktop session"
[21:18] <cyphermox> I get that
[21:19] <seb128> there are no real issue on desktop
[21:19] <cjwatson> so what should we do here for right now?  can we land my indicator-network porting branch and then I can temporarily tell proposed-migration that unity8 exists on arm64/powerpc/ppc64el?
[21:19] <cyphermox> cjwatson: yeah
[21:19] <seb128> cjwatson, seems the best solution atm yes
[21:19] <cjwatson> that can go away as it comes to exist on more arches
[21:20] <seb128> we should probably get the indicator to not depends on unity8
[21:20] <seb128> I didn't check the code but it looks like it should run without notification service
[21:20] <seb128> even if it doesn't that should be easy to fix
[21:21] <seb128> just disable notifications if there is not service
[21:21] <seb128> Wellark, ^
[21:23] <cyphermox> seb128: cjwatson: landing-007. Seems fitting
[21:23] <seb128> cyphermox, thanks
[21:24] <cyphermox> I need to run to get back home, back in a bit
[21:24] <cyphermox> robru: still around to deal with stuffs?
[21:24] <seb128> cyphermox, ttyl
[21:24] <robru> cyphermox, yep
[21:24] <cyphermox> cool
[21:24] <cyphermox> ttyl
[21:24] <robru> cyphermox, cya
[21:27] <cjwatson> seb128,cyphermox: OK, I've preemptively put the fake unity8/{arm64,powerpc,ppc64el} in place for proposed-migration
[21:27] <seb128> cjwatson, thanks
[21:27] <cjwatson> I don't really like it but it's the least bad option I think
[21:27] <cjwatson> I prefer that to arch-limitation cruft in packages
[21:28] <seb128> cjwatson, I don't think thostr is around, do you want to drive the build/test/publish for landing-007?
[21:28] <cjwatson> I can't test right now, I'm still recovering the android side of my device far enough to do dual-boot again
[21:28] <seb128> you can kick  the build
[21:28] <cjwatson> I can, yes - doing now
[21:29] <seb128> so we have a ppa to test tomorrow morning (if nobody beats us to it)
[21:29] <seb128> thanks
[21:30] <cjwatson> do we do manual testing for trivial packaging changes like that?
[21:30] <seb128> depends how confident you are that the rebuild is not going to create issue (e.g toolchain change or whatever could create problems)
[21:30] <seb128> I usually test run stuff on my desktop and ack them when I'm pretty confident it's fine
[21:30] <cjwatson> what do you mean, our toolchain is perfect
[21:31] <seb128> I didn't get unlucky so far
[21:31] <seb128> rrrright ;-)
[21:31] <cjwatson> it was last built four days ago and doko is on vacation :)
[21:31] <cjwatson> anyway, can't test-run this on desktop since conversation above
[21:32] <cjwatson> so either some kind soul can test it for me, or it can wait until I have dual-booting back tomorrow morning or so
[21:32] <seb128> I can give it a try once it's built
[21:32] <cjwatson> appreciated, thanks
[21:32] <seb128> testing on desktop should be fine though (I didn't follow on what issues your desktop is having, you mentioned device problems only that I saw)
[21:33] <cjwatson> this is a package that depends on unity8 ...
[21:33] <seb128> just install on your amd64 desktop ;-)
[21:33] <cjwatson> eh, guess I could.  not sure it would be very high-quality testing though
[21:33] <cjwatson> "yup, still broken"
[21:34] <seb128> right, but as you said it's only trivial changes
[21:34] <sergiusens> robru, mind giving me a silo for l46/u-d-m ? should be a quick one
[21:34] <robru> sergiusens, ok
[21:34] <seb128> so it's up to you on how much you feel like that needs testing
[21:34] <seb128> I just usually settle on "run at least on one arch to make sure there is no stupid mistake/issue"
[21:35] <robru> sergiusens, ok you got 14
[21:35] <robru> seb128, sorry were you addressing me or sergiusens ?
[21:35] <robru> or cjwatson...
[21:35] <robru> nm ;-)
[21:35] <seb128> robru, cjwatson
[21:36] <robru> thanks
[21:45] <sergiusens> robru, java.io.IOException: Cannot run program "/bin/bash" (in directory "/var/lib/jenkins/jobs/landing-014-1-build/workspace"): java.io.IOException: error=12, Cannot allocate memory
[21:45] <robru> sergiusens, try again? clearly infrastructural
[21:45] <sergiusens> robru, the out of memory is an indication that it will be hard to run
[21:46] <sergiusens> I tried again regardless; same failure
[21:46] <robru> sergiusens, which silo?
[21:46] <sergiusens> robru, 14
[21:47] <robru> sergiusens, oh, right at the beginning
[21:47] <robru> sergiusens, I was thinkign this would be after some time and some stuff had ahppened
[21:47] <sergiusens> robru, yeah, can't spawn /bin/bash is worrying
[21:47] <robru> awesome
[21:48] <robru> sergiusens, so cyphermox and didrocks are the only people with access to that machine
[21:48] <cjwatson> Urgh, I thought url-dispatcher was ported
[21:49] <cjwatson> It is, WTF
[21:49]  * cjwatson glares at https://launchpadlibrarian.net/169961216/buildlog_ubuntu-trusty-ppc64el.indicator-network_0.5.1%2B14.04.20140318-0ubuntu1_MANUALDEPWAIT.txt.gz
[21:49] <cjwatson> Retrying that one to give it time to think about what it's done
[21:50] <robru> sergiusens, so I'd say, retry it a few more times just in case. I texted cyphermox to ask him to hurry back and fix things
[21:52] <seb128> cjwatson, i-n works fine, tested on my n4
[21:55] <sergiusens> robru, thanks
[21:55] <cjwatson> Cool, let's just let the PPA finish publishing.  Thanks
[21:57] <seb128> yw!
[22:00] <boiko> robru: I had to add one extra component to landing-009, could you please reconfigure the silo for me?
[22:00] <robru> boiko, sure
[22:02] <robru> boiko, ahhhhh, nope
[22:02] <sergiusens> robru, jenkins now says Service Temporarily Unavailable
[22:02] <robru> boiko, jenkins just went down. only cyphermox can save it and he's afk. I texted him though
[22:04] <sergiusens> given the criticality of this infrastructure these days; can't we get 24x7 for this?
[22:05] <boiko> robru: :/
[22:05] <robru> sergiusens, theoretically we do have 24x7 between didrocks and cyphermox. just bad luck that he had to go run an errand.
[22:05] <cjwatson> two people do not make 24x7 :-)
[22:05] <sergiusens> robru, well there needs to be a backup for each timezone though
[22:05] <robru> sergiusens, but you're right. I tried to get access to this before but there was some administrative hurdle and it was decided that cyphermox would be "good enough"
[22:05] <sergiusens> at least
[22:06] <sergiusens> I'm ok with 24x5 btw :-)
[22:06] <robru> sergiusens, yes, I totally agree, but at the time, cyphermox already was "the backup" after this went down one night while didrocks was sleeping
[22:06] <sergiusens> ideally 24x7
[22:07] <sergiusens> robru, yeah, I remember that
[22:07] <cjwatson> Two people don't even make 24x5 unless you don't mind burning them out
[22:07] <robru> anyway, nothing I can do, so I might as well take lunch. back in a bit.
[22:07] <robru> tomorrow I'll press didrocks to give me that access
[22:10] <boiko> robru: so it says silo ready, but that's actually not true yet? :)
[22:10] <robru> boiko, nope, i didn't run the job. reconfig never happened. stale status
[22:11] <boiko> robru: ok
[22:21] <veebers> plars: ping, yesterday you made modifications to the autopilot release gatekeeper job. If we use the latest version of lp:ubuntu-test-cases/touch do we still need those additions?
[22:23] <plars> veebers: no, you'll be fine once you move up to tip
[22:23] <veebers> plars: awesome, thanks for the confirm
[22:45] <thomi> cyphermox: robru: is the jenkins server down? I get "Service temporarily unavailable" when trying to access http://162.213.34.102
[22:47] <thomi> cihelp - Perhaps the jenkins server has died ^^ ?
[22:49] <boiko> thomi: seems so, and it seem cyphermox is not around to get it up and running again
[22:49] <thomi> awesome
[22:50] <thomi> asac: Can you escalate this please? ^^
[22:55] <robru> thomi, I texted cyphermox, he'll be back soon-ish
[22:55] <thomi> robru: ok, thanks
[22:55] <robru> thomi, no worries
[22:56]  * robru -> back to lunch while I wait for cyphermox
[23:25] <bregma> robru, when you get back from lunch, would you be so kind as to assign a silo for line 47 and I will begin my daily ritual of human sacrifice and playing records backwards
[23:28] <robru> bregma, I will as soon as jenkins comes back up (waiting on cyphermox to restart the server which died)
[23:30] <cyphermox> oh, jenkins died?
[23:30] <thomi> cyphermox: yup :(
[23:30]  * bregma begins the occult use of certain vegetables and fruits
[23:31]  * cyphermox renames the host to "Kenny"
[23:31] <robru> cyphermox, hrrm, did you not get my texts?
[23:31] <cyphermox> I jsut saw them
[23:32] <robru> bah.
[23:32] <cyphermox> I didn't ring, I must have been walking outside at that point
[23:32] <cyphermox> I'll just take a few more minutes to figure out what's up with it instead of just rebooting it this time
[23:35] <cyphermox> fail
[23:35] <cyphermox> it quite simply got oomkilled
[23:35] <cyphermox> nothing I can do right now, but I'll work with didrocks tomorrow to migrate it to another host
[23:38] <cyphermox> in the meantime I need to come up with something to track this
[23:38] <cyphermox> jenkins is restarted
[23:41] <thomi> cyphermox: thanks!
[23:41] <robru> cyphermox, thank you!
[23:42] <robru> cyphermox, perhaps we could migrate it to a host inside the VPN, and benefit from the VPN DNS...
[23:42] <thomi> it's be really nice if one's login credentials lasted more than 10 minutes or so on that server as well :)
[23:42] <thomi> ...while we're fixing things :)
[23:42] <cyphermox> I'm kind of scared of twisting other knobs because if it ever happens that init or some other critical process gets killed, I won't be able to restart the machine myself, it will need didrocks' involvement
[23:42] <robru> thomi, *sigh* yeah
[23:43] <thomi> robru: good to know I'm not the only one who noticed :)
[23:43] <cyphermox> robru: no, it's on purpose on stack so as to be easier, more distributed to maintain than otherwise
[23:43] <robru> thomi, I use this thing *all day long* and I still have to log in every damn time
[23:43] <cyphermox> there isn't really a host for it in vpn
[23:43] <thomi> yeah
[23:43] <cyphermox> but it really also needs to be migrated to a different server farm anyway
[23:44] <robru> bregma, ok, you got 17, please build.
[23:44] <cyphermox> it's all under juju so the downtime for this stuff really should be minimal if we move things
[23:44] <robru> who else wanted stuff? sergiusens we're back online
[23:44] <sergiusens> yeah, just saw
[23:44] <robru> boiko, ok, we're back, i'm just about to reconfigure you
[23:45] <boiko> robru: nice! thanks!
[23:45] <sergiusens> mandel, still awake? building now
[23:45] <boiko> robru: if you have other priorities, you can reconfigure the silo later, I'm about to stop here
[23:45] <robru> boiko, nope nope, i'm on it
[23:46] <robru> kgunn, how's mir? really good?
[23:46] <kgunn> robru: yep...that fixed it
[23:46] <robru> cyphermox, can you kick an image before I publish mir? I did a lot of publishings today, new image would be nice i think
[23:47] <cyphermox> ack
[23:59] <imgbot>