[00:00] sec [00:00] http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-015 [00:00] Sorry, I got those links from Pawel in an email yesterday. [00:00] I don’t normally use the silo stuff, so I’m ignorant. [00:01] Is there any chance that it’s just a matter of the silo machines being too busy some of the time? [00:02] The pattern in the past was that the failures kept increasing as the workload went up on the build machines. Basically, a few days before a release milestone, things went bad. [00:02] There's no way that builder is so busy that it takes 10 seconds to run that test (which I assume should happen in under a second). [00:02] But the VM could be having a sad. Checking. [00:02] We have a number of tests that depend on finishing within certain wall clock time limits. [00:02] The test limits are pretty generous. [00:03] But, if we don’t get at least about ¼ of the performance of a Nexus 4, they’ll start failing [00:03] And I question your observation about tests and workloads, as most of the builders used for silos are physical machines that don't share with anyone else. [00:03] And the ppc/ppc64el ones (the oddballs in the group) are VMs with 2x overcommit, which should never cause an issue like this, even under extreme pressure. [00:03] If we are the only ones running on each machine, load shouldn’t be an issue. [00:04] But we are *never* seeing those failures elsewhere, except on Jenkins, and then only when Jenkins is sick. [00:04] I strongly suspect some infrastructure issue rather than a problem with our code. [00:04] Oh, Jenkins is a whole different story. [00:04] We don’t have anything in our code that would be arch specific. [00:04] But this isn't Jenkins. [00:05] Yes, I know. Just mentioning it to explain. [00:05] Test should finish in less than 2 secs, from memory [00:05] Poking at the machine now to see if it's full of hate. [00:06] Hrm, nope. The VM is perfectly happy. [00:07] GOing to retry it on the same VM for kicks. [00:07] Weird. [00:08] OK. Pawel tried several times yesterday, and kept getting the failure [00:09] Well, one of the merges here *is* called "http client test timeout". [00:09] That seems a bit suspicious, no? [00:10] Sadly, the link to the MP is a 404, so I have no idea what the actual code change was. [00:10] No. Pawel was thinking that the timeout might be too tight and upped id. [00:10] upped it. [00:10] Oh. Kay. [00:11] I’m running Pawel’s branch in my chroot at the moment, running the test in a loop. [00:11] It’s been going without failure for about 15 minutes now. [00:11] Sec, I’ll try to find a link for you to the MR [00:11] On kelsey? [00:11] https://code.launchpad.net/~unity-team/unity-scopes-api/http-client-test-timeout/+merge/247025 [00:11] Yes, whatever the 64-bit version is called. [00:12] All the failures were on 64-bit PPC [00:12] I mean, is the chroot you're playing with on kelsey02? [00:12] kelsey01 [00:12] kelsey01 is ppc64el. [00:12] You want the other. :P [00:12] Reallly? [00:13] OK, I’ll make a chroot there. [00:19] michi: Anyhow, if something fails on powerpc and nothing else (including ppc64el), and you're pretty sure there's no arch-specific code, 9 times out of 10, it would suggest an endian bug. [00:19] michi: Either bad math in the actual code somewhere causing it to take longer than it should, or bad math in the test harness giving you bogus results. [00:19] I’m very sure that it’s not an endian issue. [00:19] Bad match might be possible. [00:19] (The retry failed, not shockingly) [00:20] Strange though that it never fails on any other arch [00:20] Building on kelsy01 now [00:20] 02... [00:20] Right? [00:21] (Less confusing to call them porter-ppc64el and porter-powerpc, so you're sure you have the right onw) [00:22] porter-powerpc [00:22] Didn’t see the failure on ppc64el [00:22] But yes, it looks like you're on kelsey02 (porter-powerpc), so it's all good. :) [00:22] Ah, confused the names, sorry [00:50] infinity: Can’t reproduce the failure in my chroot build. Tried both debug and release builds [00:58] michi: Testing myself on kelsey02... [00:58] Thanks! [00:58] Could it be something really stupid, like the VM stopping for a while to snapshort itself or some such? [00:59] Nope. === charles_ is now known as charles [00:59] (A) These VMs don't do things like that but, (B) the failure would be inconsistent, and it's not. [00:59] Yes. [00:59] It was a long shot, I know :) [01:00] But I question how you built this, when the vivid-powerpc chroot didn't even have all the build-deps installed until I just fixed that now. :P [01:00] (Was missing libnet-cpp-dev) [01:01] I tried apt-get build-dep unity-scopes-api, which doesn’t work. [01:01] dpkg-checkbuilddeps in the source tree helps. [01:01] In the end, I just took all the build-deps from debian/control and did an apt-get install for those [01:02] I’ve also rewound the branch to before Pawel’s timeout hack. [01:02] Same thing. Test is running in a loop without failure. [01:02] Anyhow, the chroot is upgraded and such now, let's see if this fails for me. [01:02] I suspect it won’t. [01:03] Well, if it doesn't, then it's up to me to figure out why, which is why I'm curious. [01:03] If it does fail, I'm blaming you. :) [01:03] That sounds fair. Let’s bet a beer on it, for the next sprint ;) [01:03] The failures are consistent with one or more threads not getting CPU time. [01:03] Or it could just appear to be hung... [01:04] The build log from the Silo shows that the test failed because it didn’t get the excepted timeout exception. [01:04] tail -n 50 ~adconrad/usa/build.log [01:04] michi: ^-- What do you make of that? [01:04] looking [01:05] Try again. [01:05] Maybe because you're running your tests at the same time, and they don't play well together? [01:05] The tests are not designed to run concurrently [01:05] Exactly [01:05] We are trying to use the same network endpoints in /tmp [01:05] I’ve stopped my test [01:06] * infinity redoes this from a clean build again to replicate a buildd. [01:07] infinity: I’ve removed the remnants of my network endpoints from /tmp, so you should be OK now. [01:07] Might be better to change the tests to mkdir /tmp/$USER and put the endpoints there instead. [01:07] So far, this hasn’t been an issue for us. It’s lazy, I know [01:08] I'd recommend the tmpdir being in the build tree, not in /tmp [01:08] Unfortunately, we can’t do that. [01:08] So it doesn't generate cruft. [01:08] Oh. Why? [01:08] 107 char limitation on UNIX domain sockets means that things don’t work when they run on Jenkins. [01:08] Ahh. [01:08] Fair enough. That's not what's causing your issue anyway. [01:09] buildd chroots are fresh on every build. [01:09] How this mis-design has managed for this many years is amazing. [01:09] managed to hang around… [01:09] if open() can deal with long paths, so can bind() [01:09] end of rant [01:10] I imagine there are POSIX/XOPEN reasons why changing it isn't trivial. [01:10] Probably. But stuffing the path into the end of the struct was a silly thing to do in the first place. [01:10] The mistake was made long before POSIX [01:11] There are a lot of silly things in UNIX. :) [01:11] No, really? Have you read the UNIX Hater’s Handbook? ;) [01:11] But every time someone tries to start fresh, it never really catches on. [01:11] See: Plan 9, or Hurd. [01:11] Yes. No surprise, really. Because it works amazingly well almost all of the time. [01:12] Doesn’t mean that I can’t have a good ol’ bitch every now and then though :) [01:14] michi: So, good news (for me). It fails the same on kelsey02 with a full package build. ~adconrad/usa has the source and the build log. [01:14] Looking. That indeed is good news [01:15] So, that would point to a difference in the packages? [01:15] How did you get the build-deps installed? [01:15] michi: So, I'd recommend unpacking the actual source (dpkg-source -x foo.dsc), building it with dpkg-buildpackage -B, and then fiddling with the results. [01:16] OK, I’ll give that shot now. [01:16] Where did you get the source package? [01:16] Just want to make sure that I’m doing the same thing as you [01:16] michi: It might have something to do with libnet-cpp-dev having not been installed for your build, it might be that I upgraded the compiler to the latest version, or those might all be red herrings, and it could just be that you took a shortcut in your build that made it not the same to a real package build. [01:16] michi: I got the sources from the PPA, but you can just unpack the one in my home dir there. [01:16] OK, will do [01:17] Hmmm... [01:17] I did an apt-get for all the deps. [01:17] So that might have done it too. [01:17] I’ll try with your source first. [01:17] If I don’t see it then, I’ll use a new chroot [01:19] infinity: what build mode did you use? The default, or debug? [01:20] Forget it, doesn’t matter. [01:20] dpkg-buildpackage -B [01:22] infinity: can you blow away your endpoint dir in /tmp? [01:22] Or anything else that looks like a socket? [01:23] I think /tmp/priv, and maybe runtime-adconrad [01:25] michi: Done. [01:25] Thanks! [01:25] Still building… [01:32] Grr, didn't actually kill my testsuite successfully and those directories came back in /tmp [01:32] Hopefully that didn't break you. [01:40] infinity: you on trainguard duty tonight? [01:40] cyphermox: I'm around [01:41] robru: ah, I was just wondering because. [01:41] cyphermox: oh are you waiting for something? [01:41] rsalveti: ah, cool, I was about to ask if you had already started the rtm mtp landing [01:41] cyphermox: yeah, got a silo and just tested it [01:41] great [01:42] cyphermox: you know you have all the trainguard permissions yourself... maybe you forgot, you can assign and publish your own silos ;-) [01:43] i know [01:44] infinity: No, didn’t break me. [01:44] OK, good news: [01:44] I’m seeing the failure too now. [02:06] michi: Well, that's something. [02:10] === IMAGE 72 building (started: 20150121-02:10) === [02:23] michi, I have a changed ready to remove the problematic jenkins builders from the unity-scope-api jobs [02:23] Sweet, thank you! [02:23] I just kicked off another build. [02:23] michi, http://s-jenkins.ubuntu-ci:8080/job/unity-scopes-api-ci/541/ is doomed to fail, shall I abort it and get it restarted on the new set [02:23] Should I stop that one? [02:23] Yes please! :) [02:24] Any idea what’s causing the issue yet? [02:24] michi, ack, will get it restarted [02:26] michi, The issue appears to be heavily influenced by the configuration of the build nodes themselves. I'm leaning towards the theory that the memory and disk configuration aren't right for this workload [02:26] So the config for the working nodes is different? [02:28] They're all the same, so it's not a great theory... But there could be a relationship to the hypervisor node. I.e. the 'bad' nodes may be causing thrashing on the hypervisor itself [02:31] I see. [02:31] I don’t envy you :( [02:31] michi, it hasn't been a fun problem :( [02:31] Nope [03:10] === IMAGE RTM 205 building (started: 20150121-03:10) === [03:35] === IMAGE 72 DONE (finished: 20150121-03:35) === [03:35] === changelog: http://people.canonical.com/~ogra/touch-image-stats/72.changes === [04:02] trainguards is anyone around who can publish ? [04:02] http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-006 [04:15] === IMAGE RTM 205 DONE (finished: 20150121-04:15) === [04:15] === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/205.changes === === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [07:27] ping cihelp, jenkins builders are still wonky: https://jenkins.qa.ubuntu.com/job/thumbnailer-vivid-amd64-ci/15/console === chihchun_afk is now known as chihchun [08:41] hey satoris, made it home OK? [08:42] thomi: yep, thanks. You too, I hope. :) [08:42] heh.. yeah, but that was a bit easier [08:43] just got rid of tych0 today - we had fun the last few days [08:44] I can imagine. Did it involve beer and the steepest road in the world? [08:44] it did! and whiskey ;) [08:45] anyway, catch you 'round :D [09:16] trainguards: hi, can someone push the publish button on vivid silo #12 again? I got my code reviewed this time :$ (https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/build?delay=0sec) [09:16] pete-woods: sure! [09:20] sil2100: thanks :) [09:25] And there goes my morning work, just love GPU hang-ups === sil2100_ is now known as sil2100 [09:30] huh === chihchun is now known as chihchun_afk [09:51] trainguars hey, silo 15 fails with some internal errors - https://ci-train.ubuntu.com/job/ubuntu-landing-015-1-build/102/console [09:53] satoris: hey! [09:53] Hello. [09:54] satoris: it seems that the latest thumbnailer upload caused some issues in the gallery-app [09:55] satoris: LP: #1412442 [09:55] Launchpad bug 1412442 in Canonical System Image "Images are black when opened in gallery" [Critical,In progress] https://launchpad.net/bugs/1412442 [09:55] satoris: we would need this to be fixed ASAP, otherwise we'll have to revert thumbnailer as it's now causing regressions on the image [09:55] There are two fixes outstanding but I can't land them because jenkins fails to build. [09:56] https://jenkins.qa.ubuntu.com/job/thumbnailer-vivid-amd64-ci/16/console [09:56] A cihelp guy said to look into it yesterday but there have been no news since and my reping (an hour or few ago) got no replies. :( [09:57] satoris: I juuuust finished reading the backlog here ;) [09:57] \o/ [09:57] sil2100: when the two fixes from kaleo land, then it should start working. [09:58] I'll corral them in as soon as possible. [09:58] satoris: now I need to find what fginther did but I agree with him that the fix is around having 1) beefier workers 2) make sure they are properly spread on the physical nodes [10:05] sil2100: so if the builder thing is fixed in time the fixes can land immediately, if not then revert is probably the correct thing to do. [10:06] sil2100, hey, what's going on with https://ci-train.ubuntu.com/job/ubuntu-landing-015-1-build/104/console ? [10:07] satoris: on it, the jenkins workspace permission bits are broken (read-only) [10:07] Excellent, thanks. [10:08] damn it, I chmod'ed 755 and http://s-jenkins.ubuntu-ci:8080/job/thumbnailer-vivid-amd64-ci/18/console put it back to 711 !! [10:08] at least I'm lucky enough that it keeps using the same worker [10:08] trainguards could you pls reconfigure silo 15, thanks [10:09] satoris: rm'ing the damn dir allows progress: http://s-jenkins.ubuntu-ci:8080/job/thumbnailer-vivid-amd64-ci/19/console [10:10] satoris: is that the MP you're after though ? Or should I look at another one and keep digging ? [10:11] vila: that's the one. (original mr is https://code.launchpad.net/~fboucault/thumbnailer/save_failures/+merge/246547) [10:12] fginther: we've got a gremlin having fun at us ^ chmod'ing the dir didn't work, rm'ing it did [10:13] fginther: on cloud-worker-10 so far, not sure the gremlin will stay there or if it already broke some other dirs though... [10:13] satoris: success on http://s-jenkins.ubuntu-ci:8080/job/thumbnailer-vivid-amd64-ci/19/console [10:13] satoris: what's next ? === chihchun_afk is now known as chihchun [10:15] vila: hmm, the launchpad page is not updated with approval. Let me restart it. [10:16] satoris: ha, crap, the lower job succeeded, my bad, I need to re-run the higher level one.... /me sighs [10:16] vila: I already restarted it. [10:16] satoris: ha good, url ? [10:16] nm, stupid request [10:17] satoris: hmpf, permission denied again ;-( [10:20] satoris: ok, you're jinxed, three different workers involved, all with permission denied [10:21] That makes me a sad panda. :-( [10:21] satoris: same here ;-/ [10:21] satoris: especially since this error makes no sense [10:22] satoris: and is now spreading on different workers [10:22] Maybe it's Skynet? [10:23] pstolowski: o/ [10:24] satoris: yay, removing the 'x' bit on dirs is especially nasty, can't even think which code can do that in that context (can hardly think about a valid case for removing 'x' on a dir...) [10:26] Maybe some wildcard is doing the wrong thing? [10:26] pstolowski: the error is really strange, let's see how things look like after the reconfigure [10:30] pstolowski: reconfigured [10:36] sil2100: can you please reconfig rtm/16 for me (row 42) [10:36] mzanetti: sure thing [10:36] What has been added? [10:36] the gles twin [10:43] thanks :) [10:45] o/ [11:00] Damn, one merge is not approved [11:06] satoris: hotfixing the workers, this will take a while, I'll keep you posted === cking_ is now known as cking [11:18] vila, what is the ETA? we are blocked on this fix to land another silo this afternoon. If it cannot land soon we'll have to revert. [11:34] jibel: I'll prepare a revert in the meantime, so that everything is ready... could you confirm that installing thumbnailer 1.3+15.04.20141218~rtm.is.1.3+14.10.20141020-0ubuntu1 fixes the issues? [11:34] jibel: since we'll be reverting to that version [11:35] (which actually is a revert...) [11:35] sil2100, I'll test after lunch [11:36] jibel: I finished "fixing" the cloud workers, I'm starting to fix the cyclops ones [11:37] nerochiaro, can you speak to sil2100 about the critical gallery bug from yesterday? [11:38] sil2100, don't do anymore revert of this package or you'll overflow the version number ;) [11:38] Kaleo: I think the discussion above is about that bug ;) [11:38] sil2100, yes, and there is a pending fix in gallery IIRC [11:38] jibel: I'll fine-tune the version so it's not a revert to a revert ;p Since otherwise the version number would really be too big! [11:39] Kaleo: in gallery as well? I thought it was thumbnailer that caused the regression [11:39] sil2100, it is [11:39] sil2100, but the code in gallery was not ideal [11:39] sil2100, and making it ideal also fixes the bug [11:39] sil2100, https://code.launchpad.net/~phablet-team/gallery-app/avoid-thumbnailers-from-viewer/+merge/246997 [11:40] sil2100, status to be checked with nerochiaro [11:40] Kaleo, if you want more fixes in the gallery it has to go in silo 14 [11:40] Kaleo, it's the sync from vivid [11:40] Oh, ok, that would be great, as it would mean that even in the worst case we can still not revert [11:42] jibel, ok; nerochiaro see jibel's comment as well ^ [11:42] Kaleo: sil2100: the status is that as far as i am concerned that branch Kaleo pointed out fixes the bug in gallery. Bill was supposed to test it yesterday and let me know but it did not happen. I expect him and Pat to take a decision on this today [11:43] Kaleo: sil2100: jibel: i would say please chuck that branch in silo 14 so Bill can look and approve when he comes in [11:47] nerochiaro: that might be a bit problematic as the gallery-app silo is a sync silo, so it has no merges assigned to it [11:47] hmm [11:47] But I guess we can work-around that somehow [11:47] Will check after lunch [11:48] sil2100, 1.3+15.04.20141218~rtm.is.1.3+14.10.20141020-0ubuntu1 works on krillin/rtm 205 [11:48] * jibel -> lunch [11:48] sil2100: i am not very familiar with the silo system so please do as you feel is best. the goal is to allow bill and pat a quick path to check the patch solves the issue and approve for quick release if they are satisfied with it [11:55] cihelp: we've seen a couple of builds time out on cloud-worker-11 - is it struggling? https://jenkins.qa.ubuntu.com/job/mir-android-vivid-i386-build/961/consoleFull https://jenkins.qa.ubuntu.com/job/mir-android-vivid-i386-build/957/consoleFull [11:56] alan_g: it's in understatement ;) All cloud workers are struggling on mir builds [11:56] s/in/an/ === alan_g is now known as alan_g|lunch [12:10] hi guys [12:10] where are the ddebs from RTM published? [12:10] they don't appear to be in http://ddebs.ubuntu.com/ [12:11] and not under http://derived.archive.canonical.com/ [12:11] ogra_: do you know? [12:11] sil2100 maybe? [12:13] trainguards: help... --^ [12:15] trainguards: can I have an RTM silo for line 78, please? [12:17] Wellark: they should be on the main ddebs site [12:17] Wellark: http://ddebs.ubuntu.com/ubuntu-rtm/ [12:18] cjwatson: oh, there was a subdirectory! [12:18] cjwatson: thanks, love you! :D === alan_g|lunch is now known as alan_g [12:57] oSoMoN: on it! Was on lunch :) [13:00] sil2100, thanks [13:12] pete-woods, Hi! [13:13] pete-woods, How can I verify fix for bug 1411201 ? [13:13] bug 1411201 in Canonical System Image "Scope framework seems to be caching location" [Critical,In progress] https://launchpad.net/bugs/1411201 [13:15] satoris: the best thing we can do regarding gallery-app is releasing your fix for vivid and then re-doing the sync to ubuntu-rtm [13:15] satoris: anything else would require bfiller [13:15] bfiller: ping [13:20] sil2100: if by "my fix" you mean the ones we are trying to land once Jenkins permits? If so then absolutely yes. [13:22] sil2100, whats the question [13:22] om26er: I did it by adding a new collection of scopes in the store. it's called "canned data scopes" [13:22] om26er: one of them prints the current GPS coordinates. you can refresh the scope and check that the GPS coordinates change as you move around [13:23] om26er: the scope is called "Canned scope using location" [13:23] pete-woods, without the silo, will it not update co-ordinates ? [13:24] also do I need to run the complete test plan [13:24] om26er: well that's up to you. I can tell you that the only code that is touched is inside the location code [13:25] om26er: it doesn't update the coordinates without the silo, no [13:27] pmcgowan: so we're in a sticky situation related to the recent thumbnailer regression (that broke gallery): we have fixes from both the gallery and thumbnailer side [13:27] pete-woods, is it unity-scope-canned on launchpad ? [13:27] pmcgowan: whenever any one of them lands, we're fixed, but... [13:28] om26er: yes. but it's in the store, so you don't need to build it yourself or anything [13:28] nerochiaro, can you discuss ^^ [13:28] pmcgowan: the thumbnailer fix is blocked on jenkins build problems (which are being worked on by CI), while the gallery-app fix well, would require bfiller around since the gallery-app fix needs to be somehow incorporated into the gallery silo [13:28] pete-woods, right, I found it in the store. Its actually called 'Canned data scopes' [13:28] ^ om26er: I did it by adding a new collection of scopes in the store. it's called "canned data scopes" [13:29] sil2100, we would need to understand what the thumbnailer side fix is, I wasnt aware it could be fixed there [13:29] pmcgowan: where the gallery silo is a sync silo, so adding an additional merge cannot be done... we would have to probably just release it in vivid and sync, or ask bfiller if we can do it somehow else [13:29] pmcgowan: it seems it can be fixed from both sides [13:29] pmcgowan: so both the thumbnailer can be fixed, and the gallery can be fixed [13:29] satoris and nerochiaro need to discuss [13:30] om26er: there is more than one scope in that package. you should probably favourite the one called "Canned scope using location" [13:30] pmcgowan: the gallery fix will solve the problem as far as I am concerned, using the version of thumbnailer that is in the current image. The thumbnailer fix is something Kaleo did, more than Satoris [13:30] sil2100: ^ [13:31] Yes, I'm just trying to get the fixes through Jenkins. [13:31] nerochiaro, do we want both fixes then? [13:31] pmcgowan: both can be in, yes, but not both are required for the gallery to work again - just one is enough === MacSlow is now known as MacSlow|lunch [13:31] The thumbnailer fixes some other issues too so we might want to get it in anyway. [13:31] But currently we can't get either of them landed [13:31] pmcgowan: as sil2100 and satoris said [13:34] sil2100: would you please release the silo8? I have approved the MR [13:36] bzoltan_: o/ [13:37] sil2100: thank you [13:37] bzoltan_: need to contact an archive admin for this one [13:38] sil2100: yes, as it provides a new package [13:38] cjwatson: hey! Could you take a look at https://ci-train.ubuntu.com/job/ubuntu-landing-008-2-publish/lastSuccessfulBuild/artifact/packaging_changes_qtcreator-plugin-ubuntu_3.1.1+15.04.20150119-0ubuntu1.diff ? It's adding a new binary package and needs an ACK from an archive admin :) [13:38] cjwatson: thanks! [13:39] ogra_: how much time/trouble would it take to push an update to the sdk-libs-tools after the ubuntu-sdk-qmake-extras lands on Vivid? [13:43] sil2100: could you ask a more routine archive admin, please? I'm phasing out of this sort of thing since I've moved to the Launchpad team === marcusto_ is now known as marcustomlinson [13:43] cjwatson: ACK! Let me find someone ;) [13:45] pete-woods, ok, I can confirm the fix. Had to go out for the satellite to connect. [13:45] Now need to run the Test plan. [13:46] om26er: awesome, thanks. yeah I've been wandering around in the frost while testing it :) [13:51] jibel: the vivid not running the emulator images might be a problem this week, as rsalveti is away... [13:52] Not sure how you're supposed to do sanity testing on this then [13:52] sil2100, testing on utopic [14:05] Chipaca, can you have a look at silo 000 (ubuntu-push) Verified 2 days ago and still not published "Some merges are unapproved." [14:05] bfiller, silo 2 passed QA but can not publish "Some merges are unapproved." [14:06] jibel: let me check [14:07] jibel: all set, sil2100 mind republishing silo 2 please? [14:07] bfiller: approved? :) [14:07] sil2100: indeed :) [14:08] This is what I like [14:09] bfiller, thanks. So gallery-app in silo 14 is the only remaining sync from vivid. [14:10] jibel: that's great. we are working on the fix still for the black screen and thumbnails issue. hopefully we'll have that today [14:10] jibel: caused by the thunbmailer that was released this weekend [14:11] bzoltan_, a seed change, a rebuild of the meta and an upload of the meta [14:11] bfiller, yeah, I know the story. We need gallery app verified today to have it on tomorrow morning's image that will go through regression testing. [14:12] ogra_: OK, I will ping you once the silo8 is landed [14:12] jibel: ack, we'll either have a fix or will push to revert thumbnaiiler [14:12] bzoltan_, prepare a seed MP please to make sure it doesnt get typoed or some such [14:14] sil2100: when you have a minute, a silo for row 80 please [14:15] ogra_: What? An MP without typo is like a horse without washing machine... [14:15] true true :) [14:16] mzanetti: remember that there's unity8 in landing-021 already [14:17] uh [14:17] * mzanetti checks [14:17] sil2100: thanks for that. I would have missed it [14:17] jibel: I believe that that message is in error or outdated; they've been approved since monday [14:17] sil2100: will move my stuff into that [14:17] Oh, ok, since I already assigned a silo ;) [14:17] mzanetti: you want 80 unassigned [14:17] ? [14:17] sil2100: yep, don't need two [14:18] sil2100: sorry :/ [14:18] No worries, ok, freeing :) [14:19] mandel, what's up with rtm silo 19? [14:21] Chipaca, hm, which version should be on the phone? current version in the archive is 0.64.1+14.10.20141023.2~rtm-0ubuntu1, it looks old. [14:21] Chipaca, is it the right version? [14:22] jibel: that's likely [14:23] jibel, hi, is there anything stopping rtm silo 9 for being QA tested? I've seen the "not targeted" comment in the trello board for one of the bugs [14:24] abeato, hi, it is not on the list for ww05. Can you escalate it to pmcgowan for review or removed from the silo [14:25] pmcgowan, could you take a look at bug #1376250 ? iirc it was targeted for a landing in previous iterations [14:25] bug 1376250 in ofono (Ubuntu RTM) "i-network says "Unknown" or "No SIM" on N4 (mako), can't unlock the SIM" [High,Triaged] https://launchpad.net/bugs/1376250 [14:26] jibel, but in any case the changes for that are a pre-requirement for the fix for bug #1373388 , which is built on top of that [14:26] bug 1373388 in Canonical System Image "Allow user to change SIM slot technologies ( ex. 2G vs. 3G )" [High,Confirmed] https://launchpad.net/bugs/1373388 === MacSlow|lunch is now known as MacSlow [14:30] Chipaca, to be clear, the package we verified in silo 000 on Monday is not in the archive. Something is wrong with the publication. [14:30] sil2100, ^ can you have a look at what happened to ubuntu-push [14:30] jibel: ok, now i'm confused [14:30] sil2100: did you find anybody who could sign off the silo8? [14:31] jibel: are those checks triggered manually, or are they autoamtic? [14:32] jibel: because sil2100 told me about them being unapproved on monday, i corected that, but he'd left by the time it got done [14:32] abeato, thats a very large change in that MR [14:32] jibel: so if they are manual, then somebody needs to hit it again [14:32] sil2100, it included a fix for bug 1376282 and bug 1380662 but cannot it anywhere, so maybe I'm doing it wrong [14:32] bug 1376282 in ubuntu-push (Ubuntu RTM) "ubuntu-push-client is writing frequent debug messages to logs" [High,In progress] https://launchpad.net/bugs/1376282 [14:32] bug 1380662 in ubuntu-push (Ubuntu) "legacy apps re-set their notification status on reboot" [High,In progress] https://launchpad.net/bugs/1380662 [14:32] jibel: if they're automatic, something's broken === ev changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: mir builds are impacting all cloud builders [14:32] Chipaca, I've no idea how that part of the train works [14:32] pmcgowan, the changes for setting dynamically the slot with 3G capabilities are large [14:33] Chipaca, I was just checking that what the QA team verified actually landed [14:33] jibel: ah, ok [14:34] pmcgowan, it includes creation of new DBus interfaces and some new files [14:34]